bart again (UCX64)

[Paul Edwards]

Hi Bart.

I'm not sure what your goals are, but at one point you were
interested in the executable loader code in PDOS, to the
point that you even compiled it with a 64-bit C compiler
and pointed out issues with it.

I corrected those issues, but I don't think you used it again.

And at one point you released a generated 64-bit compiler
suitable for a Win64 environment with msvcrt.dll.

Note that at the time I was only doing 32-bit coding, so I
didn't test the fixes that I made, nor was I able to use
the C compiler for anything I was trying to do.

As of a couple of hours ago, that has changed.

There is a version of PDOS - basically I convert the UEFI
OS into a basic Win64 OS - there wasn't a lot of "glue"
required to do that.

Since we did the original activity above, there have been
new developments such as a public domain 64-bit coff
linker.

So now there is a purely public domain distribution
called "University Challenge x64" available at http://pdos.org

The only thing missing in the toolchain is a viable C compiler.

SubC is included, but it is only a subset of C90.

Can you tell me what the current status is of your public
domain C compiler and whether you are interested in
getting it to run on this new Win64 environment?

Thanks. Paul.

[Bart]

I think it's best to forget my compiler:

* I've lost interest in C and in implementing it. (It seems mainly
a tool for raising my blood pressure.)

* The compiler is non conforming in many ways, and buggy

* It's not written in C, and the tool used to create a C rendering
is being deprecated

* Its output is anyway not usually an object file; it is ASM in
a special format, directly assembled into EXE files

* There was a .OBJ format that could be produced, but that is no
longer viable, as my compiler's code is intended for low memory
(within first 2GB) at a fixed address. But modern OSes and linkers
now like to load at arbitrary, high addresses, which only works with
position-independent code.

I may anyway, at any time, decide to just delete the lot. I just don't
want any external pressures or responsibilities.

However there must be 100s of small, amateur C compilers out there, you
just have to look for them. Tiny C is open source and one of the best.

[Paul Edwards]

On Thursday, August 10, 2023 at 7:29:52 PM UTC+8, Paul Edwards wrote:

> So now there is a purely public domain distribution
> called "University Challenge x64" available at http://pdos.org

Oh - and the source code is distributed as part of the
"University Challenge 386" distribution.

I'll probably duplicate that later, but it's still mainly
"proof of concept".

BFN. Paul.

[Paul Edwards]

On Thursday, August 10, 2023 at 7:57:52 PM UTC+8, Bart wrote:

> * There was a .OBJ format that could be produced, but that is no
> longer viable, as my compiler's code is intended for low memory
> (within first 2GB) at a fixed address. But modern OSes and linkers
> now like to load at arbitrary, high addresses, which only works with
> position-independent code.

We aren't using what you would presumably call "modern
OSes and linkers". Even though they are only hours/days
old, loading below 2 GB is not an issue - we control all
components except EFI, but you can request EFI to
provide memory below a certain point, which is all that is
needed.

> I may anyway, at any time, decide to just delete the lot. I just don't
> want any external pressures or responsibilities.

Ok, sorry to hear your interests have changed.

> However there must be 100s of small, amateur C compilers out there, you
> just have to look for them. Tiny C is open source and one of the best.

Almost all of them are copyrighted.

I believe yours is the most advanced public domain one,
and then there is SubC.

As you noted - your version can't really be maintained, so the
challenge would be on to bring SubC up to your (C90) level.

BFN. Paul.

[Bart]

On 10/08/2023 13:07, Paul Edwards wrote:
> On Thursday, August 10, 2023 at 7:57:52 PM UTC+8, Bart wrote:
>
>> * There was a .OBJ format that could be produced, but that is no
>> longer viable, as my compiler's code is intended for low memory
>> (within first 2GB) at a fixed address. But modern OSes and linkers
>> now like to load at arbitrary, high addresses, which only works with
>> position-independent code.
>
> We aren't using what you would presumably call "modern
> OSes and linkers". Even though they are only hours/days
> old, loading below 2 GB is not an issue - we control all
> components except EFI, but you can request EFI to
> provide memory below a certain point, which is all that is
> needed.
>
>> I may anyway, at any time, decide to just delete the lot. I just don't
>> want any external pressures or responsibilities.
>
> Ok, sorry to hear your interests have changed.
>
>> However there must be 100s of small, amateur C compilers out there, you
>> just have to look for them. Tiny C is open source and one of the best.
>
> Almost all of them are copyrighted.

In a post-apocalyptic scenario (I think that's partly what you want this
stuff for), I don't think many will care about copyrights!

[Paul Edwards]

On Thursday, August 10, 2023 at 8:16:56 PM UTC+8, Bart wrote:

> > Almost all of them are copyrighted.

> In a post-apocalyptic scenario (I think that's partly what you want this
> stuff for), I don't think many will care about copyrights!

No, a potential apocalypse is a scenario where we MAY
need to go through the entire development of processor
again.

I am after software that has been released without strings
attached. There are not 100s of C90-compliant compilers
to choose between. There are zero.

The rest of the toolchain, and editor, and OS, are all public
domain (by various people).

Only the C compiler remains, and I have seen about 6
talented people willing to donate their work to the
public domain who have tried to write a C compiler,
but all have failed to reach C90 (some haven't
officially given up yet though).

Despite the numerous number of people who like to
claim how easy it is, without actually doing it.

BFN. Paul.

[Bart]

It's pretty much gone now together with other tools associated with C
(converting to C or from C). It only exists now as an archived ZIP on a
pen drive. I'll give it a week to see what to do about that.

It's a relief!

[Dan Cross]

PLEASE don't feed this troll.

- Dan C.

[Paul Edwards]

On Wednesday, August 16, 2023 at 9:31:54 AM UTC+8, Bart wrote:

> > I may anyway, at any time, decide to just delete the lot. I just don't
> > want any external pressures or responsibilities.

> It's pretty much gone now together with other tools associated with C
> (converting to C or from C). It only exists now as an archived ZIP on a
> pen drive. I'll give it a week to see what to do about that.
>
> It's a relief!

Ok, you don't intend to challenge the legal status of the code
already released though, do you?

I ask because someone asked me "are you sure it's public
domain?" and I wasn't sure how to answer that.

Below is what it says - no sign of an author, but that's not
really a problem - I have other code included in PDOS
where the author wishes to remain anonymous (even
though I know his name) for some reason (which I've
never asked).

I can ask him why he has a specific concern about this
code, but I think I already know the answer - he looked
where bcc came from and noted that it wasn't public
domain, and had a known author. So people may ask
more questions - well - one person already has.

Anything you can say to help me address his concerns
(before we start using this in full knowledge that it is
unsupported and not expected to be maintainable)?

Thanks. Paul.



Toy C compiler for Windows.

This code is placed in the Public Domain.

Generated C code (not original non-C sources); build with gcc or tcc.

--------------------------------------

'BCC' Compiler for 'C'-like language.

[Bart]

On 28/08/2023 11:30, Paul Edwards wrote:
> On Wednesday, August 16, 2023 at 9:31:54 AM UTC+8, Bart wrote:
>
>>> I may anyway, at any time, decide to just delete the lot. I just don't
>>> want any external pressures or responsibilities.
>
>> It's pretty much gone now together with other tools associated with C
>> (converting to C or from C). It only exists now as an archived ZIP on a
>> pen drive. I'll give it a week to see what to do about that.
>>
>> It's a relief!
>
> Ok, you don't intend to challenge the legal status of the code
> already released though, do you?
>
> I ask because someone asked me "are you sure it's public
> domain?" and I wasn't sure how to answer that.
>
> Below is what it says - no sign of an author, but that's not
> really a problem - I have other code included in PDOS
> where the author wishes to remain anonymous (even
> though I know his name) for some reason (which I've
> never asked).
>
> I can ask him why he has a specific concern about this
> code, but I think I already know the answer - he looked
> where bcc came from and noted that it wasn't public
> domain, and had a known author.

Was that the Borland C Compiler?

If so that's nothing to do with me.

The file you have remains as public domain.

You can add the name 'Bart' or 'Bart C', but I don't want to divulge my
surname as it will likely be unique worldwide.

[Paul Edwards]

On Monday, August 28, 2023 at 6:44:03 PM UTC+8, Bart wrote:

> > I can ask him why he has a specific concern about this
> > code, but I think I already know the answer - he looked
> > where bcc came from and noted that it wasn't public
> > domain, and had a known author.

> Was that the Borland C Compiler?
>
> If so that's nothing to do with me.
>
> The file you have remains as public domain.
>
> You can add the name 'Bart' or 'Bart C', but I don't want to divulge my
> surname as it will likely be unique worldwide.

Thankyou sir!

BFN. Paul.

[Anton Shepelev]

Paul Edwards:

> The only thing missing in the toolchain is a viable C
> compile

Have you checked `lice':
https://github.com/public-domain/lice

--
() ascii ribbon campaign -- against html e-mail
/\ www.asciiribbon.org -- against proprietary attachments

[Paul Edwards]

On Monday, August 28, 2023 at 10:45:17 PM UTC+8, Anton Shepelev wrote:
> Paul Edwards:
> > The only thing missing in the toolchain is a viable C
> > compile

> Have you checked `lice':
> https://github.com/public-domain/lice

Jean-Marc emailed me in 2020 and said:

I found LICE ( https://github.com/public-domain/lice ) but I've not
worked on it (I can't find the name of the original author, this is a
issue).


If he's leery, I'm leery too.

BTW, this is the same guy who was leery about cc64 from Bart,
so I went back to him with this thread and asked him if that was
good enough, and he said he was happy with that, so I have now
incorporated cc64 into the PDOS source tree:

https://sourceforge.net/p/pdos/gitcode/ci/master/tree/cc64/

And the results have been fantastic. It accepted most of
PDPCLIB, and I was happy to change some minor things
that it needed.

I encountered one presumed bug, and worked around that.

I have since encountered another presumed bug when
building PDOS-generic, and worked around that too.

And I am able to build both Windows and EFI executables,
so the stack must be aligned on a 16-byte boundary, which
was a major concern (the most major concern was whether
it would accept the C90 syntax I actually use).

I am expecting to prioritize work on UCX64 at http://pdos.org
with this new tool, which gives close enough to full closure.

Thanks Bart!

BFN. Paul.

[Michael S]

nothing

[Bart]

On 29/08/2023 03:19, Paul Edwards wrote:
> On Monday, August 28, 2023 at 10:45:17 PM UTC+8, Anton Shepelev wrote:
>> Paul Edwards:
>>> The only thing missing in the toolchain is a viable C
>>> compile
>
>> Have you checked `lice':
>> https://github.com/public-domain/lice
>
> Jean-Marc emailed me in 2020 and said:
>
> I found LICE ( https://github.com/public-domain/lice ) but I've not
> worked on it (I can't find the name of the original author, this is a
> issue).
>
>
> If he's leery, I'm leery too.
>
> BTW, this is the same guy who was leery about cc64 from Bart,
> so I went back to him with this thread and asked him if that was
> good enough, and he said he was happy with that, so I have now
> incorporated cc64 into the PDOS source tree:
>
> https://sourceforge.net/p/pdos/gitcode/ci/master/tree/cc64/
>
> And the results have been fantastic. It accepted most of
> PDPCLIB, and I was happy to change some minor things
> that it needed.
>
> I encountered one presumed bug, and worked around that.
>
> I have since encountered another presumed bug when
> building PDOS-generic, and worked around that too.

You can try raising issues here:

https://github.com/sal55/langs/tree/master

I just need to notice that something has been posted, as I don't check
it often.

[Paul Edwards]

On Wednesday, August 30, 2023 at 5:01:32 AM UTC+8, Bart wrote:
> > I encountered one presumed bug, and worked around that.
> >
> > I have since encountered another presumed bug when
> > building PDOS-generic, and worked around that too.

> You can try raising issues here:
>
> https://github.com/sal55/langs/tree/master
>
> I just need to notice that something has been posted, as I don't check
> it often.

Sorry - I thought you were very clear that this is unsupported
software and you don't want the headache? I checked the
link and it clearly says that bcc is archived.

Here are the workarounds I needed:

__PDPCLIB_HEADFUNC FILE **__gtin(void);

#define __stdin (*(__gtin()))

#ifdef __CC64__
*__stdin->fbuf = '\0';
__stdin->fbuf++;
*__stdin->fbuf = '\0';
__stdin->fbuf++;
#else
*__stdin->fbuf++ = '\0';
*__stdin->fbuf++ = '\0';
#endif



static int (*genstart)(OS *bios);

#ifdef __CC64__
rc = (*genstart)(&bios);
#else
rc = genstart(&bios);
#endif


Regardless, things are looking REALLY good and this is
likely to change my direction in life (as a Win64 vendor
on modern machines instead of scouring landfill for
Compaq BIOSes).

BFN. Paul.

[Paul Edwards]

One more issue has just come up:

From the author of pdld analyzing a problem I sent him:

The kernel32.obj produced by cc64 is lacking .drectve section which tells the linker which symbols should be exported.


We're still seeing if we can work around this problem.

BFN. Paul.

[Paul Edwards]

On Wednesday, August 30, 2023 at 3:25:27 PM UTC+8, Paul Edwards wrote:

> We're still seeing if we can work around this problem.

An "export-all-symbols" option was added to pdld and
that seems to be sufficient for my immediate needs.

BFN. Paul.

[Bart]

On 30/08/2023 04:00, Paul Edwards wrote:
> On Wednesday, August 30, 2023 at 5:01:32 AM UTC+8, Bart wrote:
>>> I encountered one presumed bug, and worked around that.
>>>
>>> I have since encountered another presumed bug when
>>> building PDOS-generic, and worked around that too.
>
>> You can try raising issues here:
>>
>> https://github.com/sal55/langs/tree/master
>>
>> I just need to notice that something has been posted, as I don't check
>> it often.
>
> Sorry - I thought you were very clear that this is unsupported
> software and you don't want the headache? I checked the
> link and it clearly says that bcc is archived.

I can't guarantee anything, but sometimes I will try and fix something I
find irksome, just for my own satisfaction.

(The bcc project is a major test program for my own language.)

> Here are the workarounds I needed:
>
> __PDPCLIB_HEADFUNC FILE **__gtin(void);
>
> #define __stdin (*(__gtin()))
>
> #ifdef __CC64__
> *__stdin->fbuf = '\0';
> __stdin->fbuf++;
> *__stdin->fbuf = '\0';
> __stdin->fbuf++;
> #else
> *__stdin->fbuf++ = '\0';
> *__stdin->fbuf++ = '\0';
> #endif
>
>
>
> static int (*genstart)(OS *bios);
>
> #ifdef __CC64__
> rc = (*genstart)(&bios);
> #else
> rc = genstart(&bios);
> #endif

The latter bug (needing to call a function pointer F as (*F)() rather
than F()), I know about. The increment one is new. However, I can't
reproduce it. This program:

-----------------------------
#include <stdio.h>

//typedef char T;
typedef short T;
//typedef int T;

typedef struct {
int dummy;
T* fbuf;
} rec;

int main(void) {
T a[] = {10,20,30,40,50};
rec x = {999, NULL};
rec* p = &x;

x.fbuf = &a[2];

printf("*p->fbuf = %d\n", *p->fbuf);

*p->fbuf++ = 77; // From your example

for (int i=0; i<5; ++i) {
printf("%d: %d\n",i, a[i]);
}
printf("*p->fbuf = %d\n", *p->fbuf);
}
-----------------------------

gives the same results with both bcc and gcc, whatever T is chosen. What
is the actual type of fbuf? And at what offset is it within __stdin? I
tried with and without that dummy field.

In any case, the code you've had to use for CC64 should work with other
compilers too.

[Paul Edwards]

Hi Bart.

I have encountered the below problem.

mingw64 works, but cc64 crashes on the fprintf.

Any idea? I will answer your other post now.

Thanks. Paul.



C:\devel\pdos\pdpclib>temp2

C:\devel\pdos\pdpclib>x86_64-w64-mingw32-gcc -S -O2 -D__WIN32__ -D__64BIT__ -I . -I ../src -o pdptest.s pdptest.c

C:\devel\pdos\pdpclib>pdas --oformat coff --64 -o pdptest.obj pdptest.s

C:\devel\pdos\pdpclib>rm -f pdptest.s

C:\devel\pdos\pdpclib>pdld -s -nostdlib --no-insert-timestamp -o pdptest.exe w32start.obj pdptest.obj msvcrt.lib

C:\devel\pdos\pdpclib>pdptest
xhello 5
yhello, world

C:\devel\pdos\pdpclib>temp

C:\devel\pdos\pdpclib>cc64 -c -out:pdptest.obj pdptest.c
Compiling pdptest.c to pdptest.obj

C:\devel\pdos\pdpclib>pdld -s -nostdlib --no-insert-timestamp --image-base 0x400000 -o pdptest.exe w32start.obj pdptest.obj msvcrt.lib

C:\devel\pdos\pdpclib>pdptest
xhello 5

C:\devel\pdos\pdpclib>type pdptest.c

int fprintf(void *stream, const char *format, ...);
int printf(const char *format, ...);

extern char *__imp__iob;

int main(void)
{
printf("xhello %d\n", 5);
fprintf(__imp__iob + 48, "yhello, world\n");
return (0);
}

C:\devel\pdos\pdpclib>

[Paul Edwards]

On Wednesday, August 30, 2023 at 6:38:30 PM UTC+8, Bart wrote:

> I can't guarantee anything, but sometimes I will try and fix something I
> find irksome, just for my own satisfaction.

Ok, but it is cc64 that I need (the thing you released to
the public domain), and that is generated code, and you
can no longer generate it, and it's nominally not
maintainable.

> than F()), I know about. The increment one is new. However, I can't
> reproduce it. This program:

I confirmed the problem is still occurring.

> rec x = {999, NULL};
> rec* p = &x;
>
> x.fbuf = &a[2];
>
> printf("*p->fbuf = %d\n", *p->fbuf);
>
> *p->fbuf++ = 77; // From your example

I am doing a function call. It's not a simple struct.
I also don't know whether you are using the same
cc64 that I am.

> gives the same results with both bcc and gcc, whatever T is chosen. What
> is the actual type of fbuf? And at what offset is it within __stdin? I
> tried with and without that dummy field.

char * and 32.

C:\devel\pdos\pdpclib>grep fbuf stdio.h | grep char
stdio.h: char *fbuf; /* file buffer - this is what all the routines

C:\devel\pdos\pdpclib>git diff .
diff --git a/pdpclib/pdptest.c b/pdpclib/pdptest.c
index b877649e..348b587b 100644
--- a/pdpclib/pdptest.c
+++ b/pdpclib/pdptest.c
@@ -14,6 +14,7 @@
#include <stdio.h>
#include <stdlib.h>
#include <string.h>
+#include <stddef.h>

static char buf[6144]; /* arbitrary buffer size */

@@ -37,6 +38,7 @@ int main(int argc, char **argv)
#endif

printf("welcome to pdptest\n");
+ printf("%d\n", offsetof(FILE, fbuf));
#ifndef SEGHACK

#if defined(__SUBC__) && defined(__64BIT__)

C:\devel\pdos\pdpclib>pdptest

welcome to pdptest
32
main function is at 00409020
allocating 10 bytes
m1 is 0009AA48
allocating 20 bytes
m2 is 000920D8
stack is around 0061FDD8
usage: pdptest [-bb/-tt/-tb/-bt] <infile> <outfile>
default is text to text copy

C:\devel\pdos\pdpclib>

__PDPCLIB_HEADFUNC FILE **__gtin(void);

#define __stdin (*(__gtin()))

Relevant code is here:

https://sourceforge.net/p/pdos/gitcode/ci/master/tree/pdpclib/

And to reproduce the problem do this:

C:\devel\pdos\pdpclib>git diff .
diff --git a/pdpclib/start.c b/pdpclib/start.c
index a2662643..e5a6c412 100644
--- a/pdpclib/start.c
+++ b/pdpclib/start.c
@@ -523,7 +523,7 @@ __PDPCLIB_API__ int CTYP __start(char *p)
__stdin->bufTech = _IOLBF;
__stdin->intBuffer = buffer1;
__stdin->fbuf = __stdin->intBuffer + 2;
-#ifdef __CC64__
+#ifdef __XCC64__

*__stdin->fbuf = '\0';
__stdin->fbuf++;
*__stdin->fbuf = '\0';

C:\devel\pdos\pdpclib>


C:\devel\pdos\pdpclib>pdmake -f makefile.c64

C:\devel\pdos\pdpclib>pdptest

C:\devel\pdos\pdpclib>

(crashes without displaying anything)


But reproducing it requires the supporting utilities from
PDOS/386 plus:

C:\devel\pdos\src>pdmake -f makek32.s64

before running the above, in order to produce kernel32.lib.
You might be able to get kernel32.lib from elsewhere.

Also during development I discovered some problems with
pdld and those are only in the source tree, not the PDOS
disk, but I don't think they are required for the above (and
that is why I didn't mention makek32.n64).

BFN. Paul.

[Bart]

On 30/08/2023 15:06, Paul Edwards wrote:
> Hi Bart.
>
> I have encountered the below problem.
>
> mingw64 works, but cc64 crashes on the fprintf.
>
> Any idea? I will answer your other post now.
>

> C:\devel\pdos\pdpclib>pdld -s -nostdlib --no-insert-timestamp --image-base 0x400000 -o pdptest.exe w32start.obj pdptest.obj msvcrt.lib
>
> C:\devel\pdos\pdpclib>pdptest
> xhello 5
>
> C:\devel\pdos\pdpclib>type pdptest.c
>
> int fprintf(void *stream, const char *format, ...);
> int printf(const char *format, ...);
>
> extern char *__imp__iob;
>
> int main(void)
> {
> printf("xhello %d\n", 5);
> fprintf(__imp__iob + 48, "yhello, world\n");
> return (0);
> }

It's not clear which C library is being linked in here. BCC is designed
to use MSVCRT.DLL (that is reflected in headers like stdio.h).

Because '__imp__iob' is not exported by msvcrt.dll; '_iob' is as a
variable, but that crashes too (even after fiddling with the generated ASM).

(Or maybe that extra '__imp_' prefix is an artefact of the linking
method that is being used, if using msvcrt.lib to access the same .dll.)

I'm not sure how well BCC links to variables exported from DLLS rather
than functions, but your test doesn't appear to use my internal linker
anyway.

I managed to get your example working by using a function instead of a
variable. See that version below. Note that in my stdio.h, 'stdout' is
defined as:

#define stdout ((FILE*)(__iob_func()+sizeof(FILE)))

sizeof(FILE) is 48.


--------------------------------------------

int fprintf(void *stream, const char *format, ...);
int printf(const char *format, ...);

extern char* __iob_func(void);

int main(void)
{
printf("xhello %d\n", 5);

fprintf(__iob_func() + 48, "yhello, world\n");
return (0);
}

[Bart]

On 30/08/2023 15:51, Paul Edwards wrote:
> On Wednesday, August 30, 2023 at 6:38:30 PM UTC+8, Bart wrote:
>
>> I can't guarantee anything, but sometimes I will try and fix something I
>> find irksome, just for my own satisfaction.
>
> Ok, but it is cc64 that I need (the thing you released to
> the public domain), and that is generated code, and you
> can no longer generate it, and it's nominally not
> maintainable.
>
> > than F()), I know about. The increment one is new. However, I can't
>> reproduce it. This program:
>
> I confirmed the problem is still occurring.
>
>> rec x = {999, NULL};
>> rec* p = &x;
>>
>> x.fbuf = &a[2];
>>
>> printf("*p->fbuf = %d\n", *p->fbuf);
>>
>> *p->fbuf++ = 77; // From your example
>
> I am doing a function call. It's not a simple struct.

I missed that completely. I'll have to do a bigger test!

[Bart]

It took me nearly half an hour to sort out the right combinations of
"*", "." and "->" operations for this test.

BCC's code goes wrong here in this equivalent code:

*(*F())->fbuf++ = 77;

It's going to be too much effort to fix. I set up the same test in my
main non-C language, where it looks like this:

F().fbuf++^:=77

(Two of the three necessary derefs are applied automatically.)

Here it works OK. I think any future efforts in the BCC code generator,
if I ever get back to it, are better spent in porting the back end from
the other compiler.

[Paul Edwards]

On Wednesday, August 30, 2023 at 10:54:10 PM UTC+8, Bart wrote:

> It's not clear which C library is being linked in here. BCC is designed
> to use MSVCRT.DLL (that is reflected in headers like stdio.h).

I have my own msvcrt.dll, built using makefile.s64 or makefile.n64

> Because '__imp__iob' is not exported by msvcrt.dll; '_iob' is as a

I believe it is - that's why I can use mingw64 and it works.

> I managed to get your example working by using a function instead of a
> variable. See that version below. Note that in my stdio.h, 'stdout' is
> defined as:
>
> #define stdout ((FILE*)(__iob_func()+sizeof(FILE)))
>
> sizeof(FILE) is 48.

Thankyou! I wasn't aware that the function __iob_func()
existed. That is good enough for my purposes and is
now working in my environment too.

Thanks a lot!

BFN. Paul.

[Bart]

On 30/08/2023 20:46, Paul Edwards wrote:
> On Wednesday, August 30, 2023 at 10:54:10 PM UTC+8, Bart wrote:
>
>> It's not clear which C library is being linked in here. BCC is designed
>> to use MSVCRT.DLL (that is reflected in headers like stdio.h).
>
> I have my own msvcrt.dll, built using makefile.s64 or makefile.n64
>
>> Because '__imp__iob' is not exported by msvcrt.dll; '_iob' is as a
>
> I believe it is - that's why I can use mingw64 and it works.

__imp_ appears to be an artefact of the linking system on Windows, and
may be to do with .lib and .a files.

If I look inside mingw64's libmsvcrt.a, I can see names starting with
__imp_. But inside msvcrt.dll itself, there are no __imp_ prefixes.

I was surprised you can use __imp_ in a source file, but it's possible
that some compilers, if you annotate a DLL imported name with
__declspec(dllimport), will add that prefix when it writes .obj files.

So that explains why you can just add it manually.

My compiler normally links directly to .DLL files (but cannot statically
link); there no .obj, .a, or .lib files involved, so that stuff isn't
needed.

[Paul Edwards]

Hi Bart.

Next error I have is:

cc64 -c -out:cclib/cclib.obj cclib/cclib.i
Compiling cclib/cclib.i to cclib/cclib.obj
In function ccpartype On line 1315 in file cclib/cclib.i

**** Code Gen Error: Block call after return ****

You can see the code here:

https://sourceforge.net/p/pdos/gitcode/ci/master/tree/pdcc/cclib/cclib.c

Change the first CC64 to XCC64 to activate the error.

It was built with makefile.n64 one level up.

BFN. Paul.

[Bart]

This is a tricky one. It can be invoked like this:

typedef struct {int a,b,c;} S;

S F(void) {
S x;
return x;
}

void G(void) {
F();
return;
F();
return;
}

'S' is a struct type that is other than 1/2/4/8 bytes in size. If you
make a call to a function that returns such a type, like my F() call
above, even if you don't use the return value, it must be just before
the final return.

Once one 'return' has been seen, you can't make another such call. This
is just due to primitive handling of such data types.

Such functions need to be adjusted to use a common return point, for
example:

void G(void) {
F();
goto retpoint;
F();
retpoint:
return;

If a return value is involved, copy it to a common variable before jumping.

(I couldn't find function ccpartype in your link.)

[Paul Edwards]

On Thursday, August 31, 2023 at 7:17:30 AM UTC+8, Bart wrote:

> Once one 'return' has been seen, you can't make another such call. This
> is just due to primitive handling of such data types.
>
> Such functions need to be adjusted to use a common return point, for
> example:
>
> void G(void) {
> F();
> goto retpoint;
> F();
> retpoint:
> return;
>
> If a return value is involved, copy it to a common variable before jumping.

Thanks for the workaround!

> (I couldn't find function ccpartype in your link.)

Names were shortened because I build on the mainframe (MVS) too:

C:\devel\pdos\pdcc>dir *.jcl
Volume in drive C has no label.
Volume Serial Number is 4E58-AF11

Directory of C:\devel\pdos\pdcc

2023-07-23 21:55 6,124 makemvs.jcl


Here is the original name:

C:\devel\pdos\pdcc\cclib>grep cc_parse_type cclib.c
cclib.c: member.type = cc_parse_type(reader);
cclib.c: cc_type cc_parse_type(cc_reader *reader)
cclib.c: param.type = cc_parse_type(reader);
cclib.c: expr.data.cast.type = cc_parse_type(reader);
cclib.c: var.type = cc_parse_type(reader); /* Now parse the type */

C:\devel\pdos\pdcc\cclib>cd include

C:\devel\pdos\pdcc\cclib\include>grep ccpartype '*'
cclib.h: #define cc_parse_type ccpartype

C:\devel\pdos\pdcc\cclib\include>


BFN. Paul.

[Bart]

On 30/08/2023 23:54, Paul Edwards wrote:

> Hi Bart.
>
> Next error I have is:
>
> cc64 -c -out:cclib/cclib.obj cclib/cclib.i
> Compiling cclib/cclib.i to cclib/cclib.obj

BTW the -out option is not needed here. The output file uses the same
filename and the same path, just the extension is changed.

So the generated .obj file is in the same folder as the .c or .i source
file. The same applies when generating executables; you can compile code
remotely.

Other C compilers may be different; gcc for example applies the right
extension, but the object file (or executable) is written to the current
directory. And others tend to copy gcc.

(Sorry, this is part of a feud I have between my compiler, and the
quirky way that gcc works.

Apparently whatever gcc does is right, even when it's wrong. If gcc
drives over a cliff, other compilers have to do the same!)

[Paul Edwards]

On Thursday, August 31, 2023 at 6:59:08 PM UTC+8, Bart wrote:

> BTW the -out option is not needed here. The output file uses the same
> filename and the same path, just the extension is changed.

Ok, thanks for the info.

Next problem I have encountered is this:

With this code:

https://sourceforge.net/p/pdos/gitcode/ci/master/tree/pdcc/cpplib/directs.c

Plus this modification:

C:\devel\pdos\pdcc>git diff .
diff --git a/pdcc/cpplib/directs.c b/pdcc/cpplib/directs.c
index 8674a696..bd515203 100644
--- a/pdcc/cpplib/directs.c
+++ b/pdcc/cpplib/directs.c
@@ -792,6 +792,13 @@ void _cpp_init_directives(cpp_reader *reader)
{
unsigned int i;

+printf("in init_directives\n");
+printf("element 0 is %p\n", directives[0].name);
+printf("element 0 alternate is %p\n", &directives[0]);
+printf("element 1 is %p\n", directives[1].name);
+printf("element 1 alternate is %p\n", &directives[1]);
+exit(0);
+
for (i = 0; i < DIRECTIVE_COUNT; i++)
{
cpp_unknown *unknown = cpp_find(reader, directives[i].name,

C:\devel\pdos\pdcc>


I see:

C:\devel\pdos\pdcc>pdcc -E abc.c
in init_directives
element 0 is 0000000000403368
element 0 alternate is 00000000004031F8
element 1 is 0200000000004033
element 1 alternate is 00000000004031F9


C:\devel\pdos\pdcc>type abc.c
int x;

C:\devel\pdos\pdcc>



I shouldn't be getting those high addresses.


The situation has been analyzed by the author of pdld, who says:

The problem seems to be cc64 wrongly accessing an address field.

If you look at .text section relocations in directs.obj, you can find relocation with "printf" with RVA 0x17A (that is the call part of the faulty "printf("element 1 is %p\n", directives[1].name);" line).

In .text section at that address the code is this:
...
48 83 ec 20 sub rsp,0x20
ff 34 25 29 00 00 00 push QWORD PTR ds:0x29 (the cc64 wrongly accessing an address field)
48 b9 19 02 00 00 00 movabs rcx,0x219
00 00 00
5a pop rdx
e8 00 00 00 00 call 0x1f (the call to printf at 0x17A)
...

The 0x29 is wrong and correctly it should be 0x28 what can be seen by looking at .data section at that address.


Are you able to comment on this?

Thanks. Paul.

[David Brown]

On 31/08/2023 12:58, Bart wrote:
> On 30/08/2023 23:54, Paul Edwards wrote:
>> Hi Bart.
>>
>> Next error I have is:
>>
>> cc64 -c -out:cclib/cclib.obj cclib/cclib.i
>> Compiling cclib/cclib.i to cclib/cclib.obj
>
>
> BTW the -out option is not needed here. The output file uses the same
> filename and the same path, just the extension is changed.
>
> So the generated .obj file is in the same folder as the .c or .i source
> file. The same applies when generating executables; you can compile code
> remotely.
>
> Other C compilers may be different; gcc for example applies the right
> extension, but the object file (or executable) is written to the current
> directory. And others tend to copy gcc.
>

Putting object files (or other generated files) in the same directory as
the source files is okay for small projects. If you've only got a
half-dozen source files, it can be tidy to keep them all in the same
directory.

If you are doing something bigger you almost invariably want to keep the
source tree and the generated files in separate directories. It makes
it much easier to see what's changed, to clean out object files, to
track source in a revision control system of some kind, to find the
source files amongst all the generated files, etc. Details, of course,
vary by person and project - too many directories and subdirectories
makes it hard to keep an overview of the files, as does too few
directories. This is known as "out of tree builds", and is the norm for
most projects above a certain size.

So whatever your default here - whether it is generating the object file
in the same directory as the source file, or generating it in the
current directory - it will be convenient in some cases, and completely
wrong in other cases.

So IMHO it's a good habit to have an "-out" (or equivalent) option in
your build files - then you know exactly where things are going.

People who use "make" have simple and common shortcuts for this. Since
you prefer not to use "make" or any alternative build system, you might
want to at least add an option to specify an output directory. Then,
for example, "cc64 -c -outdir:build src/file.c" would put the output
object file as "build/src/file.obj". You want to copy the directory
structure in the build directory, since a project written by several
people might coincidentally have matching filenames in different
directories.

[Bart]

No, sorry. I gave up on this stuff because I was being drawn into it so
much. 90% of it was having to grapple with complex C source code for
which I don't have the right tools for browsing and searching.

I realise the code generator on BCC is poor, and is buggy, which is why
I kept it as a private tool. (/My/ C code is very conservative; there it
works fine!)

What I will do however is this:

* I will take the BCC project and look at the possibility of replacing
the backend code generator with a new one.

* I can't directly use the one from my own compilers, as C is different:
I normally work with 64-bit intermediates throughout, C is mixed
32/64-bit, but mostly 32 bits

So I will do an evaluation first of how viable it will be, but if I
decide to attempt it, it will take some time so is not an immediate
solution.

That would be a better use of my time than trying to do ad hoc fixes and
patches for bugs I can't easily reproduce anyway.

Note a new backend won't fix any conformance issues. The problem with
(*F)()/F() is borderline; maybe that will fixed. The Block problem
should be. I don't want to touch the front end.

[Bart]

But putting it in the current directory is sloppy. The current location
can be arbitrary (or it might not be writeable):

c:\random>gcc \proj1\foo.c
c:\random>gcc \proj2\bar.c

Here, both compilations generate a.exe. But to cap that, both end up in
c:\random; the second overwrites the first, something you might be
unaware of.

If I do:

c:\random>gcc \proj1\foo.c
c:\random>gcc \proj2\bar.c

then there are three differences from gcc:

(1) The executables are called foo.exe and bar.exe respectively
(2) They are written to their respective folders
(3) The compiler will report exactly what it is doing so there
are fewer surprises:

Compiling \proj1\foo.c to \proj2\foo.exe

You can use -v with gcc, but it is not helpful!

> So IMHO it's a good habit to have an "-out" (or equivalent) option in
> your build files - then you know exactly where things are going.
>
> People who use "make" have simple and common shortcuts for this.  Since
> you prefer not to use "make" or any alternative build system, you might
> want to at least add an option to specify an output directory.  Then,
> for example, "cc64 -c -outdir:build src/file.c"

Actually I have exactly that option, called '-outpath', but in my main
compilers; I haven't put it into bcc because bcc is an older project.

[Scott Lurndal]

Paul Edwards <muta...@gmail.com> writes:
>On Thursday, August 31, 2023 at 6:59:08=E2=80=AFPM UTC+8, Bart wrote:
>
>> BTW the -out option is not needed here. The output file uses the same=20

>> filename and the same path, just the extension is changed.
>
>Ok, thanks for the info.
>
>Next problem I have encountered is this:

Please take it to email. This is not relevent to comp.lang.c.

[Paul Edwards]

On Thursday, August 31, 2023 at 9:45:14 PM UTC+8, Bart wrote:

> I realise the code generator on BCC is poor, and is buggy, which is why
> I kept it as a private tool. (/My/ C code is very conservative; there it
> works fine!)

Ok, thanks. I'll see if I can rework the C code to be conservative.

> So I will do an evaluation first of how viable it will be, but if I
> decide to attempt it, it will take some time so is not an immediate
> solution.

Sure. No problem. And no expectations.

This is already a decades-long endeavor anyway. It's more just
trying to understand where we stand after this latest breakthrough.

> That would be a better use of my time than trying to do ad hoc fixes and
> patches for bugs I can't easily reproduce anyway.

You should be able to reproduce my results.

I have uploaded http://pdos.org/uc386.zip which has all the
executables that get executed when running makefile.n64.
Plus it has the source code itself, so that you don't need to
go to sourceforge.

Also note that since producing the above, I have committed
a bit more development to sourceforge, but nothing related
to or that affects this issue.

> Note a new backend won't fix any conformance issues. The problem with
> (*F)()/F() is borderline; maybe that will fixed. The Block problem
> should be. I don't want to touch the front end.

Sure. The new cc64 (if it arrives) will still be public domain
though, right?

Thanks. Paul.

[Bart]

It can be. (Personally I don't care about that aspect at all.)

I can confirm that I've started an overhaul of the project, which will
have a working title of 'DD' to distinguish it from 'CC'. The first
stage is to get it to generate a new intermediate (IL) code (perhaps
within a week).

If that looks promising, then I need to turn that into ASM code. That is
likely to smaller, faster, fully ABI-conforming, and with hopefully
fewer bugs.

[Bart]

This is not necessarily a typo due to forgetting to change 'gcc' to
'bcc'. I could have decided to rename 'bcc.exe' to 'gcc.exe' for this test.

[Paul Edwards]

On Thursday, August 31, 2023 at 10:57:05 PM UTC+8, Bart wrote:

> > Sure. The new cc64 (if it arrives) will still be public domain
> > though, right?

> It can be. (Personally I don't care about that aspect at all.)

If you don't care, then please keep it public domain, because
that is the whole point - I care, and I am working with people
who care. And all the people I work with have attempted or
are still attempting to write a public domain C90-compliant
compiler, but nobody has reached cc64 level yet.

> I can confirm that I've started an overhaul of the project, which will
> have a working title of 'DD' to distinguish it from 'CC'. The first
> stage is to get it to generate a new intermediate (IL) code (perhaps
> within a week).
>
> If that looks promising, then I need to turn that into ASM code. That is
> likely to smaller, faster, fully ABI-conforming, and with hopefully
> fewer bugs.

Ok, cool.

Note that it was suggested to take this to email, but I
personally don't think it is off-topic. If you do, my email
address is mutazilah AT gmail DOT com.

I have a new problem regardless.

C:\devel\pdos\pdmake>pdmake -f makefile.n64
rm -f main.obj read.obj rule.obj variable.obj xmalloc.obj hashtab.obj ../pdpclib/x64supb.obj pdmake.exe
pdcc -E -I. -I./hashtab -I../pdpclib -D__WIN32__ -D__NOBIVA__ -D__64BIT__ -D__CC64__ -o main.i main.c
cc64 -c -out:main.obj main.i
Compiling main.i to main.obj
rm -f main.i
pdcc -E -I. -I./hashtab -I../pdpclib -D__WIN32__ -D__NOBIVA__ -D__64BIT__ -D__CC64__ -o read.i read.c
cc64 -c -out:read.obj read.i
Compiling read.i to read.obj
rm -f read.i
pdcc -E -I. -I./hashtab -I../pdpclib -D__WIN32__ -D__NOBIVA__ -D__64BIT__ -D__CC64__ -o rule.i rule.c
cc64 -c -out:rule.obj rule.i
Compiling rule.i to rule.obj
rm -f rule.i
pdcc -E -I. -I./hashtab -I../pdpclib -D__WIN32__ -D__NOBIVA__ -D__64BIT__ -D__CC64__ -o variable.i variable.c
cc64 -c -out:variable.obj variable.i
Compiling variable.i to variable.obj
rm -f variable.i
pdcc -E -I. -I./hashtab -I../pdpclib -D__WIN32__ -D__NOBIVA__ -D__64BIT__ -D__CC64__ -o xmalloc.i xmalloc.c
cc64 -c -out:xmalloc.obj xmalloc.i
Compiling xmalloc.i to xmalloc.obj
rm -f xmalloc.i
pdcc -E -I. -I./hashtab -I../pdpclib -D__WIN32__ -D__NOBIVA__ -D__64BIT__ -D__CC64__ -o ./hashtab/hashtab.i ./hashtab/hashtab.c
cc64 -c -out:hashtab.obj ./hashtab/hashtab.i
Compiling ./hashtab/hashtab.i to hashtab.obj
rm -f ./hashtab/hashtab.i
pdld -s -nostdlib --no-insert-timestamp --image-base 0x400000 -o pdmake.exe ../pdpclib/w32start.obj main.obj read.obj rule.obj variable.obj xmalloc.obj hashtab.obj ../pdpclib/x64supb.obj ../pdpclib/msvcrt.lib

C:\devel\pdos\pdmake>pdmake --help
before

C:\devel\pdos\pdmake>


C:\devel\pdos\pdmake>git diff .
diff --git a/pdmake/hashtab/hashtab.c b/pdmake/hashtab/hashtab.c
index 57184ed4..00e43d9b 100644
--- a/pdmake/hashtab/hashtab.c
+++ b/pdmake/hashtab/hashtab.c
@@ -18,6 +18,7 @@

#include <math.h>
#include <stddef.h>
+#include <stdio.h>

#include "hashtab.h"

@@ -85,6 +86,7 @@ static int rehash (struct hashtab *hashtab, size_t target_size)
{
struct hashtab old_hashtab = *hashtab;
struct hashtab_entry *entry;
+ double ggg;

size_t i;

@@ -96,6 +98,11 @@ static int rehash (struct hashtab *hashtab, size_t target_size)
}

hashtab->probe_limit = max (internal_log2 (hashtab->size), MINIMAL_PROBE_LIMIT);
+
+ printf("before\n");
+ ggg = hashtab->max_load_factor * hashtab->size;
+ printf("after\n");
+
hashtab->max_number_of_elements = ceil (hashtab->max_load_factor * hashtab->size);

/* Allocates size + probe_limit + 1 so no bounds checking needs to be done. */

C:\devel\pdos\pdmake>


A double multiplied by a long long is crashing.

If I cast the long long to int, it doesn't crash.

Code is all in sourceforge.

Note that it could be related to the assembler support
routines. We have converted some of your bcclib.asm
into intel syntax, which can be found here:

https://sourceforge.net/p/pdos/gitcode/ci/master/tree/pdpclib/x64supb.asm


And relevant stuff copied here, in case you can see
something we have done wrong in the conversion:


# These routines were copied (and then modified) from bcclib.asm generated
# by the public domain cc64, and are used for cc64
# (Converted to PDAS .intel_syntax noprefix by guessing.)

.globl m$ufloat_r64u32
m$ufloat_r64u32:
mov ecx, ecx # clear top half (already done if value just moved there)
cvtsi2sd xmm15, rcx
ret

.globl m$ufloat_r32u32
m$ufloat_r32u32:
mov ecx, ecx
cvtsi2ss xmm15, rcx
ret

.globl m$ufloat_r64u64
m$ufloat_r64u64:
cmp ecx, 0
jl fl1
#number is positive, so can treat like i64
cvtsi2sd xmm15, rcx
ret
fl1: #negative value
and rcx, QWORD PTR mask63[rip] #clear top bit (subtract 2**63)
cvtsi2sd xmm15, rcx
addsd xmm15, QWORD PTR offset64[rip] #(add 2**63 back to result)
ret

.globl m$ufloat_r32u64
m$ufloat_r32u64:
cmp ecx, 0
jl fl2
#number is positive, so can treat like i64
cvtsi2ss xmm15, rcx
ret
fl2: #negative value
and rcx, QWORD PTR mask63[rip] #clear top bit (subtract 2**63)
cvtsi2ss xmm15, rcx
addss xmm15, DWORD PTR offset32[rip] #(add 2**63 back to result)
ret

.section rdata
mask63:
.quad 0x7fffffffffffffff
offset64:
.quad 9223372036854775808 # 2**63 as r64
offset32:
.quad 9223372036854775808 # 2**63 as r32



Thanks. Paul.

[David Brown]

So don't do that.

Make sure you are in the appropriate directory, then compile - or give
the output file name directly. As I said, whatever default you use, it
will be wrong sometimes.

> Here, both compilations generate a.exe. But to cap that, both end up in
> c:\random; the second overwrites the first, something you might be
> unaware of.

If you are not aware of that, you'll learn pretty quickly!

>
> If I do:
>
>  c:\random>gcc \proj1\foo.c
>  c:\random>gcc \proj2\bar.c
>
> then there are three differences from gcc:
>
>  (1) The executables are called foo.exe and bar.exe respectively
>  (2) They are written to their respective folders
>  (3) The compiler will report exactly what it is doing so there
>      are fewer surprises:
>
>      Compiling \proj1\foo.c to \proj2\foo.exe
>
> You can use -v with gcc, but it is not helpful!

Nor is it helpful for the compiler to tell me what it is doing -
generally I know what it is doing - it is doing what I told it to do.
It is only if it can't do that (due to some error) that I want to be told.

Again, different defaults suit different uses and different people.
Plenty of gcc's defaults are inappropriate for me, and I think should be
different - but your compiler's defaults are no better. You only
/think/ that your compiler's defaults are good, because they suit you
personally - don't expect them to be ideal for anyone else. For any big
program, excluding ones they write themselves to use themselves, some of
the default settings will be sub-optimal or unusable.

So your compiler's defaults are not worse than any others, nor are they
better - except for your own personal tastes.

>
>> So IMHO it's a good habit to have an "-out" (or equivalent) option in
>> your build files - then you know exactly where things are going.
>>
>> People who use "make" have simple and common shortcuts for this.
>> Since you prefer not to use "make" or any alternative build system,
>> you might want to at least add an option to specify an output
>> directory.  Then, for example, "cc64 -c -outdir:build src/file.c"
>
> Actually I have exactly that option, called '-outpath', but in my main
> compilers; I haven't put it into bcc because bcc is an older project.
>

Fair enough.

Do you also have a "-quiet" option to hide non-essential messages?
That's also something I like in compilers and other tools, if it is not
the default - though again, preferences vary.

[Kaz Kylheku]

On 2023-08-31, Bart <b...@freeuk.com> wrote:
> On 31/08/2023 13:36, David Brown wrote:
>> So whatever your default here - whether it is generating the object file
>> in the same directory as the source file, or generating it in the
>> current directory - it will be convenient in some cases, and completely
>> wrong in other cases.
>
> But putting it in the current directory is sloppy. The current location
> can be arbitrary (or it might not be writeable):
>
> c:\random>gcc \proj1\foo.c
> c:\random>gcc \proj2\bar.c
>
> Here, both compilations generate a.exe. But to cap that, both end up in
> c:\random; the second overwrites the first, something you might be
> unaware of.

Nobody cares about this in the world of building components from C.

The build systems by and large operate from the assumption that
the current working directory is the top-level build directory.

If you do

$ make -f /path/to/project/build/Makefile

it will not work. The correct ways, if you're not in that
directory are any of these:

$ cd /path/to/project/build; make

or

$ make -C /path/to/project/build

or, if the name of the makefile is nonstandard:

$ make -C /path/to/project/build -f Makefile.foo

The argument to -f is considered from the directory that
was changed into with -C.

While you could probably make a Makefile that can be dispatched from
anywhere without changing the current working directory, I suspect there
is zero demand.

If you end up feeding resolvd, absolute paths to your tools, that's
actually a negative. The __FILE__ macro resolves to something that
makes no ssense on the target system where the program is running
like "/home/bob/open-source-projects/foo/src/parsere.c"instead of just
"src/parser.c".

--
TXR Programming Language: http://nongnu.org/txr
Cygnal: Cygwin Native Application Library: http://kylheku.com/cygnal
Mastodon: @Kazi...@mstdn.ca

[Bart]

On 31/08/2023 18:36, David Brown wrote:
> On 31/08/2023 16:30, Bart wrote:
>> On 31/08/2023 13:36, David Brow

>> But putting it in the current directory is sloppy. The current
>> location can be arbitrary (or it might not be writeable):
>>
>>   c:\random>gcc \proj1\foo.c
>>   c:\random>gcc \proj2\bar.c
>>
>
> So don't do that.
>
> Make sure you are in the appropriate directory, then compile - or give
> the output file name directly.  As I said, whatever default you use, it
> will be wrong sometimes.

But it's an extra thing that could be easily have been done right.
Compilers work for us, not us for them.

Suppose gcc decided to put the output files in a root directory, or some
place where it would be a very bad idea to write or overwrite a file.

You can't just fob people off with 'So don't do that'; it needs to be
fixed. But then neither can you further fob them off with: 'It's always
done that, and further, one person in 1000, or some makefile from 1974,
depends on it, so we can't change it, ever'.

>> Here, both compilations generate a.exe. But to cap that, both end up
>> in c:\random; the second overwrites the first, something you might be
>> unaware of.
>
> If you are not aware of that, you'll learn pretty quickly!

It may not have crossed your mind, or if it had, your might assume that
two distinct a.exe files were produced.

>>
>> If I do:
>>
>>   c:\random[gcc \proj1\foo.c
>>   c:\random>gcc \proj2\bar.c
>>
>> then there are three differences from gcc:
>>
>>   (1) The executables are called foo.exe and bar.exe respectively
>>   (2) They are written to their respective folders
>>   (3) The compiler will report exactly what it is doing so there
>>       are fewer surprises:
>>
>>       Compiling \proj1\foo.c to \proj2\foo.exe
>>
>> You can use -v with gcc, but it is not helpful!
>
> Nor is it helpful for the compiler to tell me what it is doing -

If the compiler is doing multiple files, especially a slow compiler,
then it is highly useful to know where it's up to, or what it's stuck on.

But this seems to be a Linux thing: if I do 'cp *.c dest', then nothing
is output, until you get the prompt back. So, did work, did it copy
anything, was it one big file, or lots of small ones?

If I do 'copy *.c test' on Windows, it shows each file copied, and it
tells how many files were copied in all. The 'cp' command needs '-v' to
force to show what it's doing.

The defaults are backwards.

> generally I know what it is doing - it is doing what I told it to do. It
> is only if it can't do that (due to some error) that I want to be told.
>
> Again, different defaults suit different uses and different people.
> Plenty of gcc's defaults are inappropriate for me, and I think should be
> different - but your compiler's defaults are no better.  You only
> /think/ that your compiler's defaults are good, because they suit you
> personally

No, they make more sense for casual use from a command line for anybody.

> Do you also have a "-quiet" option to hide non-essential messages?
> That's also something I like in compilers and other tools, if it is not
> the default - though again, preferences vary.

Yes, I think it's -q. If a lot of files are being processed, then you
might want to turn it off (or if timing, it can make a small difference).

However gcc's -v option generates 40 times as much output as my compiler
without -q. So it's either far too verbose, or not enough.

[Kaz Kylheku]

On 2023-08-31, Kaz Kylheku <864-11...@kylheku.com> wrote:
> On 2023-08-31, Bart <b...@freeuk.com> wrote:
>> On 31/08/2023 13:36, David Brown wrote:
>>> So whatever your default here - whether it is generating the object file
>>> in the same directory as the source file, or generating it in the
>>> current directory - it will be convenient in some cases, and completely
>>> wrong in other cases.
>>
>> But putting it in the current directory is sloppy. The current location
>> can be arbitrary (or it might not be writeable):
>>
>> c:\random>gcc \proj1\foo.c
>> c:\random>gcc \proj2\bar.c
>>
>> Here, both compilations generate a.exe. But to cap that, both end up in
>> c:\random; the second overwrites the first, something you might be
>> unaware of.
>
> Nobody cares about this in the world of building components from C.
>
> The build systems by and large operate from the assumption that
> the current working directory is the top-level build directory.

In fact, I should add, there is a practice of separating source
and build directories.

Any properly constructed AutoConf project supports this:

$ mkdir build-dir
$ cd build-dir
build-dir $ /path/to/some/project/configure

You create a build directory and call a configure script located
elsewhere. It prepares that build directory for building the program.


build-dir $ make

The build references source files in /path/to/some/project.

It drops object files here, inthis directory. Or some child like obj/
depending on the exact build system.

You don't want to be dropping binaries in the sae place where the
sources are located.

*THAT* location may be read-only!

Building sources that sit on a read-only mounted filesystem is a thing.

The MIT XWindow system devised a scheme for dealing with this: the lndir
utility.

With lndir, you create a parallel tree to the target source tree,
populated with symlinks:


$ mkdir build-dir
$ cd build-dir
build-dir$ lndir /path/to/some/project .

A directory structure skeleton is created mirroring that of the
target projet, and populated with symlinks to each of its files.

lndir's man page says:

"This is usually useful for maintaining source code for different
machine architectures. You create a shadow directory containing links
to the real source, which you will have usually mounted from a
remote machine."

I was once employed producing a from-scratch embedded Linux distro,
and doing kernel work, toolchain support and such.

I religiously used separate build directories for everything I built.
A few programs refused to cooperate. For those that couldn't be patched,
I reached for lndir.

The Linux kernel cannot (or couldn't at the time?) support separate
build directories; I used lndir and it worked like a charm. That allowed
me to build the same tree for x86 and MIPS without its cooperation.

(The one thing that defeated lndir was that goddamed ASDF build system
for Common Lisp. Internally, it called (truepath ...) which resolves
all symlinks, and then it calculated object paths from the resolved
source paths.)

But anyway, if you're sitting in a different tree from where your
source files are, you rarely want object files to be pooped into
that tree, instead of this one here.

If you do, you're an oddball, and nobody will listen to you;
they will say, just change to that directory and work there.

[Bart]

On 31/08/2023 20:17, Kaz Kylheku wrote:
> On 2023-08-31, Bart <b...@freeuk.com> wrote:
>> On 31/08/2023 13:36, David Brown wrote:
>>> So whatever your default here - whether it is generating the object file
>>> in the same directory as the source file, or generating it in the
>>> current directory - it will be convenient in some cases, and completely
>>> wrong in other cases.
>>
>> But putting it in the current directory is sloppy. The current location
>> can be arbitrary (or it might not be writeable):
>>
>> c:\random>gcc \proj1\foo.c
>> c:\random>gcc \proj2\bar.c
>>
>> Here, both compilations generate a.exe. But to cap that, both end up in
>> c:\random; the second overwrites the first, something you might be
>> unaware of.
>
> Nobody cares about this in the world of building components from C.

I guess that's because people using off-the-shelf tools are forced to do
things the way the tools dictate. They don't have a choice!

After a while they become inured enough to think that's the only way it
can be.

>
> The build systems by and large operate from the assumption that
> the current working directory is the top-level build directory.

So, you have to build things in-situ. To build multiple projects, you
have to navigate from folder to folder.

Whereas I can build all my language projects from one location, for example:

c:\demo>mm \ax\aa
Compiling \ax\aa.m------ to \ax\aa.exe

c:\demo>mm \cx\cc
Compiling \cx\cc.m------ to \cx\cc.exe

c:\demo>mm \qx\qq
Compiling \qx\qq.m------ to \qx\qq.exe

c:\demo>mm \mx\mm
Compiling \mx\mm.m------ to \mx\mm.exe

> If you do
>
> $ make -f /path/to/project/build/Makefile
>
> it will not work.

Why doesn't the tool just navigate to that path? And maybe, navigate
back to the start point when it's done?

Oh, I get it, 'zero demand'!

(You can see I don't use makefiles; most of them would consist of one line.)

The correct ways, if you're not in that
> directory are any of these:
>
> $ cd /path/to/project/build; make
>
> or
>
> $ make -C /path/to/project/build
>
> or, if the name of the makefile is nonstandard:
>
> $ make -C /path/to/project/build -f Makefile.foo
>
> The argument to -f is considered from the directory that
> was changed into with -C.
>
> While you could probably make a Makefile that can be dispatched from
> anywhere without changing the current working directory, I suspect there
> is zero demand.

I was right...

> If you end up feeding resolvd, absolute paths to your tools, that's
> actually a negative. The __FILE__ macro resolves to something that
> makes no ssense on the target system where the program is running
> like "/home/bob/open-source-projects/foo/src/parsere.c"instead of just
> "src/parser.c".

__FILE__ is a compile-time thing. But people do feed absolute or
sometimes relative paths to their compilers; the OP did so for example.

Also, that Baby X RC project was built with a command line like this:

gcc *.c abc\*.c def\*.c

Whatever path is provided for a source file, is what ends up as a a
prefix to __FILE__. You don't want a dozen files, all called foo.c but
in different folders, to all show "foo.c" in their __FILE__ macros; that
is not helpful!

[Ben Bacarisse]

sc...@slp53.sl.home (Scott Lurndal) writes:

> Paul Edwards <muta...@gmail.com> writes:

>>Ok, thanks for the info.
>>
>>Next problem I have encountered is this:
>
> Please take it to email. This is not relevent to comp.lang.c.

It is certainly niche, but it's all about C. I'd say these posts are
among the most topical there have been in a while. As it happens, they
don't interest me much, but that not the same thing at all.

--
Ben.

[Keith Thompson]

Bart <b...@freeuk.com> writes:
[...]

> I can confirm that I've started an overhaul of the project, which will
> have a working title of 'DD' to distinguish it from 'CC'. The first
> stage is to get it to generate a new intermediate (IL) code (perhaps
> within a week).

There's a common Unix file conversion tool called "dd". Do whatever you
like with that information.

https://pubs.opengroup.org/onlinepubs/9699919799/utilities/dd.html

--
Keith Thompson (The_Other_Keith) Keith.S.T...@gmail.com
Will write code for food.
void Void(void) { Void(); } /* The recursive call of the void */

[Bart]

The location that you invoke the compiler from may be read-only!

For example, DVD-ROM drive, if you still have one.

> Building sources that sit on a read-only mounted filesystem is a thing.

I can build and run applications in my language on a read-only device
like this:

ms prog

This runs the app from source without creating an executable file.

And yet, when you do:

gcc hello.c

it will write a.out or a.exe in the same folder.

> If you do, you're an oddball, and nobody will listen to you;
> they will say, just change to that directory and work there.

I guess I'm an oddball. I routinely modify source files and write new
EXEs in the same folder. What's the point of mucking about with a
special folder just for the one EXE file?

For a user installation, then sure, but a user installation is something
removed from a developer's directory tree.

The impression I get is that in Linux, the entire file system is
considered to be one giant developer's tree, and installed software is
part of it.

[Keith Thompson]

Bart <b...@freeuk.com> writes:
[...]

> If the compiler is doing multiple files, especially a slow compiler,
> then it is highly useful to know where it's up to, or what it's stuck
> on.
>
> But this seems to be a Linux thing: if I do 'cp *.c dest', then
> nothing is output, until you get the prompt back. So, did work, did it
> copy anything, was it one big file, or lots of small ones?
>
> If I do 'copy *.c test' on Windows, it shows each file copied, and it
> tells how many files were copied in all. The 'cp' command needs '-v'
> to force to show what it's doing.
>
> The defaults are backwards.

[...]

I acknowledge that you prefer tools to be verbose, and that you have
perfectly valid reasons to want a compiler to show what it's doing and
for a file copying program to print the name of each file as it's
copying it.

Please acknowledge that others have valid preferences that differ from
yours. I'm not even asking you to understand why, or to like it, just
that different valid preferences exist.

Or don't. Up to you.

[Kenny McCormack]

In article <87o7in7...@nosuchdomain.example.com>,

Keith Thompson <Keith.S.T...@gmail.com> wrote:
...
>I acknowledge that you prefer tools to be verbose, and that you have
>perfectly valid reasons to want a compiler to show what it's doing and
>for a file copying program to print the name of each file as it's
>copying it.
>
>Please acknowledge that others have valid preferences that differ from
>yours. I'm not even asking you to understand why, or to like it, just
>that different valid preferences exist.

Yes, but...

The problem with this form of argumentation is that it fails to acknowledge
the difference between actual constructive belief and mere defense of the
status quo.

I.e., one often (and by "often", I mean almost universally) gets the
impression that people who criticize posters like "Bart" aren't doing so
out of a genuine belief that they are right and Bart is wrong, but rather
out of general fear of change (i;e., the fear of the cognitive dissonance
that acceptance of Bart's ideas would cause them).

I get this a lot in the responses I get to my own posts.

--
The randomly chosen signature file that would have appeared here is more than 4
lines long. As such, it violates one or more Usenet RFCs. In order to remain
in compliance with said RFCs, the actual sig can be found at the following URL:
http://user.xmission.com/~gazelle/Sigs/Noam

[Scott Lurndal]

Bart <b...@freeuk.com> writes:
>On 31/08/2023 18:36, David Brown wrote:
>> On 31/08/2023 16:30, Bart wrote:
>>> On 31/08/2023 13:36, David Brow
>
>>> But putting it in the current directory is sloppy. The current
>>> location can be arbitrary (or it might not be writeable):
>>>
>>>   c:\random>gcc \proj1\foo.c
>>>   c:\random>gcc \proj2\bar.c
>>>
>>
>> So don't do that.
>>
>> Make sure you are in the appropriate directory, then compile - or give
>> the output file name directly.  As I said, whatever default you use, it
>> will be wrong sometimes.
>
>But it's an extra thing that could be easily have been done right.
>Compilers work for us, not us for them.
>
>Suppose gcc decided to put the output files in a root directory, or some
>place where it would be a very bad idea to write or overwrite a file.

Why do you thing gcc would "decide" to do anything? You do understand
that non-root users cannot "put the output files in a root directory",
right?

And developers don't run as root. Linux is far more secure than windows.

[Scott Lurndal]

Bart <b...@freeuk.com> writes:
>On 31/08/2023 18:36, David Brown wrote:
>
>> Nor is it helpful for the compiler to tell me what it is doing -
>
>If the compiler is doing multiple files, especially a slow compiler,
>then it is highly useful to know where it's up to, or what it's stuck on.

$ ps -ef | grep gcc

>
>But this seems to be a Linux thing: if I do 'cp *.c dest', then nothing
>is output, until you get the prompt back. So, did work, did it copy
>anything, was it one big file, or lots of small ones?

If it doesn't say anything, it worked. If it doesn't work it will
say something. If your really want to know what it's doing, use
-v.

>The defaults are backwards.

No.

[Bart]

On 31/08/2023 21:17, Keith Thompson wrote:
> Bart <b...@freeuk.com> writes:
> [...]
>> If the compiler is doing multiple files, especially a slow compiler,
>> then it is highly useful to know where it's up to, or what it's stuck
>> on.
>>
>> But this seems to be a Linux thing: if I do 'cp *.c dest', then
>> nothing is output, until you get the prompt back. So, did work, did it
>> copy anything, was it one big file, or lots of small ones?
>>
>> If I do 'copy *.c test' on Windows, it shows each file copied, and it
>> tells how many files were copied in all. The 'cp' command needs '-v'
>> to force to show what it's doing.
>>
>> The defaults are backwards.
> [...]
>
> I acknowledge that you prefer tools to be verbose,

Not at all. 'Verbose' might refer to the approx 5KB of output I get from
'gcc hello.c -v', as shown below.

I don't want that at all. What I'm asking for is more of an
acknowledgement and confirmation of what I'm asked the tool to do. That
seems reasonable enough to me.

Typing 'bcc hello' simply gives me this:

Compiling hello.c to hello.exe

Presumably you consider /that/ verbose? If so then what do you call all
that crap below!



--------------------------------

Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=C:/tdm/bin/../libexec/gcc/x86_64-w64-mingw32/13.2.0/lto-wrapper.exe
Target: x86_64-w64-mingw32
Configured with: /gcc-13.2.0/configure --prefix=/w64devkit
--with-sysroot=/w64devkit/x86_64-w64-mingw32
--with-native-system-header-dir=/include --target=x86_64-w64-mingw32
--host=x86_64-w64-mingw32 --enable-static --disable-shared --with-pic
--with-gmp-include=/deps/include --with-gmp-lib=/deps/lib
--with-mpc-include=/deps/include --with-mpc-lib=/deps/lib
--with-mpfr-include=/deps/include --with-mpfr-lib=/deps/lib
--enable-languages=c,c++ --enable-libgomp --enable-threads=posix
--enable-version-specific-runtime-libs --disable-dependency-tracking
--disable-multilib --disable-nls --disable-win32-registry
--enable-mingw-wildcard CFLAGS_FOR_TARGET=-Os CXXFLAGS_FOR_TARGET=-Os
LDFLAGS_FOR_TARGET=-s CFLAGS=-Os CXXFLAGS=-Os LDFLAGS=-s
Thread model: posix
Supported LTO compression algorithms: zlib
gcc version 13.2.0 (GCC)
COLLECT_GCC_OPTIONS='-v' '-mtune=generic' '-march=x86-64' '-dumpdir' 'a-'
C:/tdm/bin/../libexec/gcc/x86_64-w64-mingw32/13.2.0/cc1.exe -quiet -v
-iprefix C:/tdm/bin/../lib/gcc/x86_64-w64-mingw32/13.2.0/ -isysroot
C:/tdm/bin/../x86_64-w64-mingw32 -D_REENTRANT hello.c -quiet -dumpdir a-
-dumpbase hello.c -dumpbase-ext .c -mtune=generic -march=x86-64 -version
-o C:\Users\xxxxx\AppData\Local\Temp\ccHzEGHk.s
GNU C17 (GCC) version 13.2.0 (x86_64-w64-mingw32)
compiled by GNU C version 13.2.0, GMP version 6.2.1, MPFR version
4.1.0, MPC version 1.2.1, isl version none
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
ignoring duplicate directory
"C:/tdm/lib/gcc/../../lib/gcc/x86_64-w64-mingw32/13.2.0/include"
ignoring nonexistent directory
"C:/tdm/bin/../x86_64-w64-mingw32/w64devkit/lib/gcc/x86_64-w64-mingw32/13.2.0/../../../../include"
ignoring duplicate directory
"C:/tdm/lib/gcc/../../lib/gcc/x86_64-w64-mingw32/13.2.0/include-fixed"
ignoring duplicate directory
"C:/tdm/lib/gcc/../../lib/gcc/x86_64-w64-mingw32/13.2.0/../../../../x86_64-w64-mingw32/include"
ignoring nonexistent directory
"C:/tdm/bin/../x86_64-w64-mingw32/mingw/include"
#include "..." search starts here:
#include <...> search starts here:
C:/tdm/bin/../lib/gcc/x86_64-w64-mingw32/13.2.0/include
C:/tdm/bin/../lib/gcc/x86_64-w64-mingw32/13.2.0/include-fixed

C:/tdm/bin/../lib/gcc/x86_64-w64-mingw32/13.2.0/../../../../x86_64-w64-mingw32/include
End of search list.
Compiler executable checksum: 055af4833c5f81a4fd6295dedebfeca6
COLLECT_GCC_OPTIONS='-v' '-mtune=generic' '-march=x86-64' '-dumpdir' 'a-'
as -v -o C:\Users\xxxxx\AppData\Local\Temp\ccDDjtgp.o
C:\Users\xxxxx\AppData\Local\Temp\ccHzEGHk.s
GNU assembler version 2.40 (x86_64-w64-mingw32) using BFD version (GNU
Binutils) 2.40
COMPILER_PATH=C:/tdm/bin/../libexec/gcc/x86_64-w64-mingw32/13.2.0/;C:/tdm/bin/../libexec/gcc/
LIBRARY_PATH=C:/tdm/bin/../lib/gcc/x86_64-w64-mingw32/13.2.0/;C:/tdm/bin/../lib/gcc/;C:/tdm/bin/../lib/gcc/x86_64-w64-mingw32/13.2.0/../../../../x86_64-w64-mingw32/lib/../lib/;C:/tdm/bin/../lib/gcc/x86_64-w64-mingw32/13.2.0/../../../../lib/;C:/tdm/bin/../lib/gcc/x86_64-w64-mingw32/13.2.0/../../../../x86_64-w64-mingw32/lib/;C:/tdm/bin/../lib/gcc/x86_64-w64-mingw32/13.2.0/../../../
COLLECT_GCC_OPTIONS='-v' '-mtune=generic' '-march=x86-64' '-dumpdir' 'a.'
C:/tdm/bin/../libexec/gcc/x86_64-w64-mingw32/13.2.0/collect2.exe
-plugin
C:/tdm/bin/../libexec/gcc/x86_64-w64-mingw32/13.2.0/liblto_plugin.dll
-plugin-opt=C:/tdm/bin/../libexec/gcc/x86_64-w64-mingw32/13.2.0/lto-wrapper.exe
-plugin-opt=-fresolution=C:\Users\xxxxx\AppData\Local\Temp\cc9Tr00r.res
-plugin-opt=-pass-through=-lmingw32 -plugin-opt=-pass-through=-lgcc
-plugin-opt=-pass-through=-lmoldname -plugin-opt=-pass-through=-lmingwex
-plugin-opt=-pass-through=-lmsvcrt -plugin-opt=-pass-through=-lkernel32
-plugin-opt=-pass-through=-lpthread -plugin-opt=-pass-through=-ladvapi32
-plugin-opt=-pass-through=-lshell32 -plugin-opt=-pass-through=-luser32
-plugin-opt=-pass-through=-lkernel32 -plugin-opt=-pass-through=-lmingw32
-plugin-opt=-pass-through=-lgcc -plugin-opt=-pass-through=-lmoldname
-plugin-opt=-pass-through=-lmingwex -plugin-opt=-pass-through=-lmsvcrt
-plugin-opt=-pass-through=-lkernel32
--sysroot=C:/tdm/bin/../x86_64-w64-mingw32 -m i386pep -Bdynamic
C:/tdm/bin/../lib/gcc/x86_64-w64-mingw32/13.2.0/../../../../x86_64-w64-mingw32/lib/../lib/crt2.o
C:/tdm/bin/../lib/gcc/x86_64-w64-mingw32/13.2.0/crtbegin.o
-LC:/tdm/bin/../lib/gcc/x86_64-w64-mingw32/13.2.0
-LC:/tdm/bin/../lib/gcc
-LC:/tdm/bin/../lib/gcc/x86_64-w64-mingw32/13.2.0/../../../../x86_64-w64-mingw32/lib/../lib
-LC:/tdm/bin/../lib/gcc/x86_64-w64-mingw32/13.2.0/../../../../lib
-LC:/tdm/bin/../lib/gcc/x86_64-w64-mingw32/13.2.0/../../../../x86_64-w64-mingw32/lib
-LC:/tdm/bin/../lib/gcc/x86_64-w64-mingw32/13.2.0/../../..
C:\Users\xxxxx\AppData\Local\Temp\ccDDjtgp.o -lmingw32 -lgcc -lmoldname
-lmingwex -lmsvcrt -lkernel32 -lpthread -ladvapi32 -lshell32 -luser32
-lkernel32 -lmingw32 -lgcc -lmoldname -lmingwex -lmsvcrt -lkernel32
C:/tdm/bin/../lib/gcc/x86_64-w64-mingw32/13.2.0/crtend.o
COLLECT_GCC_OPTIONS='-v' '-mtune=generic' '-march=x86-64' '-dumpdir' 'a.'

[Scott Lurndal]

Keith Thompson <Keith.S.T...@gmail.com> writes:
>Bart <b...@freeuk.com> writes:
>[...]
>> I can confirm that I've started an overhaul of the project, which will
>> have a working title of 'DD' to distinguish it from 'CC'. The first
>> stage is to get it to generate a new intermediate (IL) code (perhaps
>> within a week).
>
>There's a common Unix file conversion tool called "dd". Do whatever you
>like with that information.

For consistency, since 'cc' stands for 'C Compiler', he should
use 'dc', for 'D Compiler'. But that conflicts with the standard
'desktop RPN calculator' application, dc.

[Bart]

<Literally both face palms on face>

If it doesn't say anything, it worked? Since Windows 10, a crashing
program doesn't say anything; it silently fails.

And when there is a lot going on with gcc, you can get loads of warnings
and other crap scrolling up the screen. So, was there an "error:" in
there or not? I've no idea if it worked!

I have to see if there is a recent .exe just created.

Or sometimes I get a clue by there being a pause after the last message,
meaning it's doing the rest of it.

(Or maybe it's just crashed.)

Or I have to supply options to tell it to stop after one error (I have
to find it first).

Or I have to capture the output twice (first with >, second after I've
remembered it's 2>), so that I can use a text editor to search for
"error:" strings.

What an effing palaver.

gcc is not the only program like that, but it seems typical of where it
came from.

>> The defaults are backwards.
>
> No.

Delude yourself if you like.

[Keith Thompson]

Bart <b...@freeuk.com> writes:
> On 31/08/2023 21:17, Keith Thompson wrote:
>> Bart <b...@freeuk.com> writes:
>> [...]
>>> If the compiler is doing multiple files, especially a slow compiler,
>>> then it is highly useful to know where it's up to, or what it's stuck
>>> on.
>>>
>>> But this seems to be a Linux thing: if I do 'cp *.c dest', then
>>> nothing is output, until you get the prompt back. So, did work, did it
>>> copy anything, was it one big file, or lots of small ones?
>>>
>>> If I do 'copy *.c test' on Windows, it shows each file copied, and it
>>> tells how many files were copied in all. The 'cp' command needs '-v'
>>> to force to show what it's doing.
>>>
>>> The defaults are backwards.
>> [...]
>> I acknowledge that you prefer tools to be verbose,
>
> Not at all. 'Verbose' might refer to the approx 5KB of output I get
> from 'gcc hello.c -v', as shown below.

Your preference is for tools to be more verbose than what a lot of other
people prefer.

Printing one line of output for a successful compilation or file copy is
more verbose than printing nothing.

> I don't want that at all. What I'm asking for is more of an
> acknowledgement and confirmation of what I'm asked the tool to
> do. That seems reasonable enough to me.

And I just acknowledged that your preference is valid.

> Typing 'bcc hello' simply gives me this:
>
> Compiling hello.c to hello.exe
>
> Presumably you consider /that/ verbose? If so then what do you call
> all that crap below!

I consider that more verbose than my own preference, which is for it to
print nothing on success. If gcc printed the one-line status report
that you prefer, it wouldn't particularly bother me, but I'm content
with its current behavior.

Let me clarify: I have no preference for what bcc should print, since I
don't use it. If I did, I probably wouldn't bother to figure out how to
suppress the "Compiling ..." message.

I suppose it would be nice if gcc had an option to print output that's
less verbose than what it prints with "-v", perhaps one terse line for
each program it invokes. Since I'm not a gcc maintainer, I'm not in a
position to do anything about it. Since the current behavior doesn't
bother me, I'm not going to ask the gcc maintainers to do anything about
it.

The point of my previous post was to ask you to acknowledge that others
may have valid preferences that differ from yours. You refuse to do
so. Got it.

[Scott Lurndal]

Bart <b...@freeuk.com> writes:
>On 31/08/2023 23:07, Scott Lurndal wrote:
>> Bart <b...@freeuk.com> writes:
>>> On 31/08/2023 18:36, David Brown wrote:
>>>
>>>> Nor is it helpful for the compiler to tell me what it is doing -
>>>
>>> If the compiler is doing multiple files, especially a slow compiler,
>>> then it is highly useful to know where it's up to, or what it's stuck on.
>>
>> $ ps -ef | grep gcc
>>
>>>
>>> But this seems to be a Linux thing: if I do 'cp *.c dest', then nothing
>>> is output, until you get the prompt back. So, did work, did it copy
>>> anything, was it one big file, or lots of small ones?
>>
>> If it doesn't say anything, it worked. If it doesn't work it will
>> say something. If your really want to know what it's doing, use
>> -v.
>
>
><Literally both face palms on face>
>
>If it doesn't say anything, it worked? Since Windows 10, a crashing
>program doesn't say anything; it silently fails.

You're talking about building unix/linux tools. On *nix, a crashing program
_will_ say something (if not directly, then indirectly via the
shell return status $?).

$ cc -o /tmp/a /tmp/a.c
$ /tmp/a
Memory fault
$ printf '0x%x\n' $(( $? ))
0x10b <----- Signal 11 (SIGSEGV)

$ cat /tmp/a.c
int
main(int argc, const char **argv, const char **envp)
{
const char *cp = (const char *)0;
return *cp;
}

https://pubs.opengroup.org/onlinepubs/9699919799/functions/V2_chap02.html#tag_15_13

>
>And when there is a lot going on with gcc, you can get loads of warnings

>and other crap scrolling up the screen.\

Acually, I don't get any warnings. -Wall -Werror.

$ pwd
/work/ws/vsim/20220509/vsim
$ make -s HUSHCOMPILE=@
VSIM_BUILT
COMPILE bct.cpp
COMPILE command_table.cpp
COMPILE contention_protocol.cpp
COMPILE dcp.cpp
COMPILE dcp_header.cpp
COMPILE disassembler.cpp
COMPILE ebcdic.cpp
COMPILE file_logger.cpp
COMPILE mcs.cpp
COMPILE mux_logger.cpp
COMPILE netport.cpp
COMPILE osdep.cpp
COMPILE pollselect.cpp
COMPILE pool.cpp
COMPILE protocol.cpp
COMPILE serialport.cpp
COMPILE station.cpp
COMPILE syslog_logger.cpp
COMPILE thread.cpp
COMPILE timer.cpp
COMPILE timer_manager.cpp
COMPILE dlp.cpp
COMPILE iocb.cpp
COMPILE card_unit.cpp
COMPILE tape_unit.cpp
COMPILE disk_unit.cpp
COMPILE file_card_unit.cpp
COMPILE file_tape_unit.cpp
COMPILE st_tape_unit.cpp
COMPILE file_disk_unit.cpp
COMPILE fips_tape_dlp.cpp
COMPILE gcr_dlp.cpp
COMPILE scsi_disk_dlp.cpp
COMPILE 5n_dlp.cpp
COMPILE odt_dlp.cpp
COMPILE uniline_dlp.cpp
COMPILE htseq_dlp.cpp
COMPILE card_reader_dlp.cpp
COMPILE train_printer_dlp.cpp
COMPILE ssp_dlp.cpp
COMPILE ssp.cpp
COMPILE qwik_dlp.cpp
COMPILE buffered_printer_dlp.cpp
COMPILE card_punch_dlp.cpp
COMPILE ht_dcp_dlp.cpp
COMPILE ht_dpdc_dlp.cpp
COMPILE isc_dlp.cpp
COMPILE scsi_tape_dlp.cpp
COMPILE telcom_dlp.cpp
BUILD ../../lib/libdlp_5n.so
BUILD ../../lib/libdlp_buffered_printer.so
BUILD ../../lib/libdlp_fips_tape.so
BUILD ../../lib/libdlp_gcr.so
BUILD ../../lib/libdlp_ht_dcp.so
BUILD ../../lib/libdlp_ht_dpdc.so
BUILD ../../lib/libdlp_htseq.so
BUILD ../../lib/libdlp_isc.so
BUILD ../../lib/libdlp_qwik.so
BUILD ../../lib/libdlp_punch.so
BUILD ../../lib/libdlp_reader.so
BUILD ../../lib/libdlp_scsi_disk.so
BUILD ../../lib/libdlp_scsi_tape.so
BUILD ../../lib/libdlp_ssp.so
BUILD ../../lib/libdlp_telcom.so
BUILD ../../lib/libdlp_tpr.so
BUILD ../../lib/libdlp_odt.so
BUILD ../../lib/libdlp_uniline.so
COMPILE system.cpp
COMPILE blt.cpp
COMPILE memory.cpp
COMPILE processor.cpp
COMPILE processor_rd.cpp
COMPILE index_register.cpp
COMPILE operand.cpp
COMPILE misc_ops.cpp
COMPILE arith_ops.cpp
COMPILE compare_ops.cpp
COMPILE branch_ops.cpp
COMPILE move_ops.cpp
COMPILE search_ops.cpp
COMPILE omega_ops.cpp
COMPILE hardware_call.cpp
COMPILE time_ops.cpp
COMPILE environment.cpp
COMPILE environment_table.cpp
COMPILE kernel_data_area.cpp
COMPILE float.cpp
COMPILE mop.cpp
COMPILE toggles.cpp
COMPILE intflags.cpp
HOSTCOMPILE makedigits
COMPILE digits.cpp
COMPILE add.cpp
COMPILE sub.cpp
COMPILE op_acm.cpp
COMPILE op_add.cpp
COMPILE op_and.cpp
COMPILE op_asp.cpp
COMPILE op_ate.cpp
COMPILE op_b2d.cpp
COMPILE op_bct.cpp
COMPILE op_brt.cpp
COMPILE op_brv.cpp
COMPILE op_brv_reva.cpp
COMPILE op_bst.cpp
COMPILE op_cio.cpp
COMPILE op_cio_reva.cpp
COMPILE op_cpn.cpp
COMPILE op_cps.cpp
COMPILE op_d2b.cpp
COMPILE op_dec.cpp
COMPILE op_edt.cpp
COMPILE op_ext.cpp
COMPILE op_hbk.cpp
COMPILE op_hbr.cpp
COMPILE op_hcl.cpp
COMPILE op_hsh.cpp
COMPILE op_iad.cpp
COMPILE op_ias.cpp
COMPILE op_idl.cpp
COMPILE op_iio.cpp
COMPILE op_ild.cpp
COMPILE op_ils.cpp
COMPILE op_imi.cpp
COMPILE op_ims.cpp
COMPILE op_imu.cpp
COMPILE op_inc.cpp
COMPILE op_ioc.cpp
COMPILE op_ioc_reva.cpp
COMPILE op_ipc.cpp
COMPILE op_iss.cpp
COMPILE op_ist.cpp
COMPILE op_isu.cpp
COMPILE op_ker.cpp
COMPILE op_lix.cpp
COMPILE op_lok.cpp
COMPILE op_mls.cpp
COMPILE op_mop.cpp
COMPILE op_mvc.cpp
COMPILE op_mvd.cpp
COMPILE op_mvl.cpp
COMPILE op_mvr.cpp
COMPILE op_mvs.cpp
COMPILE op_mvw.cpp
COMPILE op_not.cpp
COMPILE op_ntr.cpp
COMPILE op_orr.cpp
COMPILE op_piq.cpp
COMPILE op_raa.cpp
COMPILE op_rad.cpp
COMPILE op_ras.cpp
COMPILE op_rds.cpp
COMPILE op_rdt.cpp
COMPILE op_rdv.cpp
COMPILE op_ret.cpp
COMPILE op_rld.cpp
COMPILE op_rms.cpp
COMPILE op_rmu.cpp
COMPILE op_rss.cpp
COMPILE op_rst.cpp
COMPILE op_rsu.cpp
COMPILE op_sde.cpp
COMPILE op_sea.cpp
COMPILE op_six.cpp
COMPILE op_sll.cpp
COMPILE op_slt.cpp
COMPILE op_smf.cpp
COMPILE op_spio.cpp
COMPILE op_sst.cpp
COMPILE op_srd.cpp
COMPILE op_stb.cpp
COMPILE op_stt.cpp
COMPILE op_sub.cpp
COMPILE op_sze.cpp
COMPILE op_trn.cpp
COMPILE op_tst.cpp
COMPILE op_ven.cpp
COMPILE op_whr.cpp
COMPILE analyze.cpp
COMPILE base.cpp
COMPILE breakpoint.cpp
COMPILE cf.cpp
COMPILE channel.cpp
COMPILE clear.cpp
COMPILE command.cpp
COMPILE control.cpp
COMPILE delete.cpp
COMPILE dis.cpp
COMPILE dump.cpp
COMPILE exchange.cpp
COMPILE haltwait.cpp
COMPILE iocbdump.cpp
COMPILE iodump.cpp
COMPILE load.cpp
COMPILE mem.cpp
COMPILE mp.cpp
COMPILE quit.cpp
COMPILE rle.cpp
COMPILE run.cpp
COMPILE save.cpp
COMPILE search.cpp
COMPILE so.cpp
COMPILE start.cpp
COMPILE state.cpp
COMPILE status.cpp
COMPILE step.cpp
COMPILE stop.cpp
COMPILE table.cpp
COMPILE to.cpp
COMPILE trace.cpp
COMPILE main.cpp
COMPILE hub.cpp
CONVERT td830.bdf
CONVERT td830B.bdf
COMPILE main.cpp
COMPILE t27.cpp
COMPILE env.cpp
COMPILE menu.cpp
COMPILE vsim_dcomm.cpp
COMPILE tapecopy.c
COMPILE tapedump.c
COMPILE vdir.c
COMPILE ebc2asc.c
COMPILE deblock.c
COMPILE tapeconvert.c
COMPILE main.cpp
COMPILE b974.cpp
COMPILE rw_alfa.cpp
COMPILE rw_arap.cpp
COMPILE rw_cdat.cpp
COMPILE rw_clab.cpp
COMPILE rw_cnst.cpp
COMPILE rw_corp.cpp
COMPILE rw_ctim.cpp
COMPILE rw_cuid.cpp
COMPILE rw_data.cpp
COMPILE rw_dlab.cpp
COMPILE rw_dom.cpp
COMPILE rw_envf.cpp
COMPILE rw_eqiv.cpp
COMPILE rw_infl.cpp
COMPILE rw_kats.cpp
COMPILE rw_lngh.cpp
COMPILE rw_mod.cpp
COMPILE rw_numr.cpp
COMPILE rw_orig.cpp
COMPILE rw_para.cpp
COMPILE rw_pict.cpp
COMPILE rw_proc.cpp
COMPILE rw_ptnm.cpp
COMPILE rw_scon.cpp
COMPILE rw_stak.cpp
COMPILE rw_stru.cpp
COMPILE rw_sync.cpp
COMPILE rw_urts.cpp
COMPILE rw_var.cpp
COMPILE op_default.cpp
COMPILE op_lix.cpp
COMPILE op_vv.cpp
COMPILE op_vvvv.cpp
COMPILE op_aaaaaa.cpp
COMPILE op_afbf_aaaaaa.cpp
COMPILE op_afbf_aaaaaa_bbbbbb.cpp
COMPILE op_afbf_aaaaaa_bbbbbb_cccccc.cpp
COMPILE assembler.cpp
COMPILE codegen.cpp
COMPILE field_length.cpp
COMPILE icm5.cpp
COMPILE line.cpp
COMPILE lister.cpp
COMPILE main.cpp
COMPILE memimage.cpp
COMPILE symbol.cpp
COMPILE symbol_table.cpp
COMPILE linker.cpp
COMPILE lmain.cpp
COMPILE main.cpp
COMPILE so.cpp
COMPILE to.cpp
COMPILE submit.cpp
COMPILE help.cpp
COMPILE spo.cpp
COMPILE quit.cpp
COMPILE rje.cpp
COMPILE main.cpp
$ file vsim
vsim: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.6.32, BuildID[sha1]=e863f72a2f645bf4c00a77935a1433e39967e7a7, not stripped

[Kaz Kylheku]

On 2023-08-31, Bart <b...@freeuk.com> wrote:
> On 31/08/2023 20:17, Kaz Kylheku wrote:
>> On 2023-08-31, Bart <b...@freeuk.com> wrote:
>>> On 31/08/2023 13:36, David Brown wrote:
>>>> So whatever your default here - whether it is generating the object file
>>>> in the same directory as the source file, or generating it in the
>>>> current directory - it will be convenient in some cases, and completely
>>>> wrong in other cases.
>>>
>>> But putting it in the current directory is sloppy. The current location
>>> can be arbitrary (or it might not be writeable):
>>>
>>> c:\random>gcc \proj1\foo.c
>>> c:\random>gcc \proj2\bar.c
>>>
>>> Here, both compilations generate a.exe. But to cap that, both end up in
>>> c:\random; the second overwrites the first, something you might be
>>> unaware of.
>>
>> Nobody cares about this in the world of building components from C.
>
> I guess that's because people using off-the-shelf tools are forced to do
> things the way the tools dictate. They don't have a choice!

That is false; the tools are quite flexible and will do things according
to someone else's preferences.

The tools won't do that by default; that would break them for everyone
who relies on them to behave in their default way.

> After a while they become inured enough to think that's the only way it
> can be.
>
>>
>> The build systems by and large operate from the assumption that
>> the current working directory is the top-level build directory.
>
> So, you have to build things in-situ.

No you don't; but it works well that way given how the system is
designed. Why swim against the tidee if there is no benefit.

> To build multiple projects, you
> have to navigate from folder to folder.

The biggest consumers of multipel projects are distros and distro
maintainers. GNU/Linux (and other) distros are certainly not built by
someone who manually navigates from folder to folder.

The distro build does that.

From the build person's point of view, that's one thing to run,
in one place.

> Whereas I can build all my language projects from one location, for example:
>
> c:\demo>mm \ax\aa
> Compiling \ax\aa.m------ to \ax\aa.exe

gcc does this for object files:

gcc path/to/foo.c -c

produces path/to/foo.o.

The default executable is a.out, or else whatever you pass to -o
is taken verbatim.

It's common for .o files to be together with the .c files,
but for the linked executable to be in the root directory
of the project.

However, the -c option isn't useful if we want to have
separate build and source directories, or separate object
directories for different architectures.

The default build recipe does the trick; you just set up
the dependencies correctly, e.g.

objs/x86_64/parser/scanner.o: src/parser/scanner.c

The recipe will compile src/parser/scanner.c and
use -o objs/x86_64/parser/scanner.o .

> c:\demo>mm \cx\cc
> Compiling \cx\cc.m------ to \cx\cc.exe
>
> c:\demo>mm \qx\qq
> Compiling \qx\qq.m------ to \qx\qq.exe
>
> c:\demo>mm \mx\mm
> Compiling \mx\mm.m------ to \mx\mm.exe

That's just your preference, it would be better to have cc.exe, qe.exe
and mm.exe right here in this directory instead of being buried in
subdirectories.

There are Makefiles that bury things that way; they are irksome.
Hey, make worked; where is the program??? Ah, in src/output,
whatever for ...

>> If you do
>>
>> $ make -f /path/to/project/build/Makefile
>>
>> it will not work.
>
> Why doesn't the tool just navigate to that path?

Well, because it's a file, and not a directory.

So the question is why doesn't it navigate to the path
/path/to/project/build and then run Makefile?

Because navigating to a directory is what the -C option does,
and only that option.

(If you don't like those conventions, you can write a mymake
script which recognizes your preferred conventions and then
generates an equivalent call to make.)

> And maybe, navigate
> back to the start point when it's done?

That's not necessary; when a child process does chdir(), the parent
is not affected. When you run a tool that changes directory, your
current directory is not affected.

I'm pretty sure Windows works that way too.

[Kaz Kylheku]

On 2023-08-31, Kenny McCormack <gaz...@shell.xmission.com> wrote:
> In article <87o7in7...@nosuchdomain.example.com>,
> Keith Thompson <Keith.S.T...@gmail.com> wrote:
> ...
>>I acknowledge that you prefer tools to be verbose, and that you have
>>perfectly valid reasons to want a compiler to show what it's doing and
>>for a file copying program to print the name of each file as it's
>>copying it.
>>
>>Please acknowledge that others have valid preferences that differ from
>>yours. I'm not even asking you to understand why, or to like it, just
>>that different valid preferences exist.
>
> Yes, but...
>
> The problem with this form of argumentation is that it fails to acknowledge
> the difference between actual constructive belief and mere defense of the
> status quo.
>
> I.e., one often (and by "often", I mean almost universally) gets the
> impression that people who criticize posters like "Bart" aren't doing so
> out of a genuine belief that they are right and Bart is wrong, but rather

I genuinely believe that I'm right when I say that

1. The environment is infinitely flexible; you can shape it to work
how you want.

2. There is no unanimous agreement that its default behaviors and conventions
are the "correct" ones.

3. Talk about how default behaviors and conventions should be otherwise
is largely unproductive. Refere to (1).

> out of general fear of change (i;e., the fear of the cognitive dissonance
> that acceptance of Bart's ideas would cause them).

Not really. In the world of C an Unix, there are enough loonies that
over the years you end up working with a large number of different
preferences for this and that.

Most people who have weird or alternative preferences just code them up
into their build system instead of complaining that Their Way isn't the
default one imposed on everyone else, so that everyone else should
customize, rather than they.

Bart could easily do the same: make Unix and Linux suit his preferences
by writing scripts that work with his conventions and translate that to
suitable invocations of the tools.

If you want "gcc foo/bar.c" o produce a program "foo/bar", you
can just have a wrapper. Etc.

Now, of course, setting up your own environment how you like doesn't fix
other people's projects that you're trying to build.

Building other people's projects can suck. It sucks not just for
Bart but for the rest of us who don't mind the defaults and conventions.

FOSS projects are written by volunteers. They don't owe you anything,
including a build system that works how you would like.

It's sad that people do counterproductive things to their programs, like
vandalize their build systems with Autoconf, just because that's what
others have done and they read about it in some blog or tutorial.

Most FOSS maintainers don't read this newsgroup so you literally
don't achive a thing by complaining here about how FOSS projects
are hard bo build.

If you think that some FOSS program is really useful to you and
you regularly engage its build system, which sucks, you can contribute
a better one. Better to ask first whether they would be interested,
before wasting your time.

[Keith Thompson]

Bart <b...@freeuk.com> writes:
> On 31/08/2023 23:07, Scott Lurndal wrote:

[...]

>> If it doesn't say anything, it worked. If it doesn't work it will
>> say something. If your really want to know what it's doing, use
>> -v.
>
> <Literally both face palms on face>
>
> If it doesn't say anything, it worked? Since Windows 10, a crashing
> program doesn't say anything; it silently fails.

[...]

If gcc fails, it returns a status that indicates failure. If you're
using a Bourne-like shell, you can examine the value of $?. In a
Windows command shell, `echo %errorlevel%`. In PowerShell, $? is True
or False, and $LASTEXITCODE is the status value.

I've configured bash to show me any non-zero exit value after running a
command. I don't know whether you can do that on Windows.

[Bart]

On 01/09/2023 00:46, Keith Thompson wrote:
> Bart <b...@freeuk.com> writes:
>> On 31/08/2023 23:07, Scott Lurndal wrote:
> [...]
>>> If it doesn't say anything, it worked. If it doesn't work it will
>>> say something. If your really want to know what it's doing, use
>>> -v.
>>
>> <Literally both face palms on face>
>>
>> If it doesn't say anything, it worked? Since Windows 10, a crashing
>> program doesn't say anything; it silently fails.
> [...]
>
> If gcc fails, it returns a status that indicates failure. If you're
> using a Bourne-like shell, you can examine the value of $?. In a
> Windows command shell, `echo %errorlevel%`. In PowerShell, $? is True
> or False, and $LASTEXITCODE is the status value.
>
> I've configured bash to show me any non-zero exit value after running a
> command. I don't know whether you can do that on Windows.
>

You're sort of missing the point. Is it really that hard to do:

puts("Compilation failed");
exit(1);

rather than:

exit(1);

Are you so averse to 'verbosity' then a one-line message reporting a
failure cannot be tolerated?

I find it bizarre that you like your programs so silent that you need to
employ external means to find if they ran successfully or not!

I think the most output I've had from a compiler was nearly 30,000 lines
of warnings and notes. But no errors; it had produced a working
executable. However that was not obvious.

So despite being so verbose (pointlessly so, since WTH am I supposed to
do with all that output) I still wasn't sure whether it had worked.

I guess, yet another wrapper needed to take care of yet another task
that is the compiler's job? I might as well write my own compiler! (Oh,
wait...)

[Paul Edwards]

On Friday, September 1, 2023 at 8:44:20 AM UTC+8, Bart wrote:

> You're sort of missing the point. Is it really that hard to do:
>
> puts("Compilation failed");
> exit(1);

That is already being done - an error message is printed
when there is an error.

What is not being done is:

puts("Compilation succeeded");
exit(0);

So on Windows - if there was a crash - not a deliberate
exit - you don't know if it was successful or not.

But if Windows had the ability to display "crashed", the
same as that Unix option, you would know.

I personally run everything under "pdmake" and any non-zero
exit code - or Windows crash - causes pdmake to complain and
terminate.

BFN. Paul.


P.S. I have replied to your email - please check your spam folder if
you didn't receive it, or return the conversation to here if we are
having communication issues.

[Chris M. Thomasson]

On 8/31/2023 6:09 PM, Paul Edwards wrote:
> On Friday, September 1, 2023 at 8:44:20 AM UTC+8, Bart wrote:
>
>> You're sort of missing the point. Is it really that hard to do:
>>
>> puts("Compilation failed");
>> exit(1);
>
> That is already being done - an error message is printed
> when there is an error.
>
> What is not being done is:
>
> puts("Compilation succeeded");
> exit(0);
>
> So on Windows - if there was a crash - not a deliberate
> exit - you don't know if it was successful or not.

You mean blue screen?

[Paul Edwards]

On Friday, September 1, 2023 at 9:11:15 AM UTC+8, Chris M. Thomasson wrote:
> On 8/31/2023 6:09 PM, Paul Edwards wrote:
> > On Friday, September 1, 2023 at 8:44:20 AM UTC+8, Bart wrote:
> >
> >> You're sort of missing the point. Is it really that hard to do:
> >>
> >> puts("Compilation failed");
> >> exit(1);
> >
> > That is already being done - an error message is printed
> > when there is an error.
> >
> > What is not being done is:
> >
> > puts("Compilation succeeded");
> > exit(0);
> >
> > So on Windows - if there was a crash - not a deliberate
> > exit - you don't know if it was successful or not.
> You mean blue screen?

Real life example on Windows 10:

printf("before\n");

ggg = hashtab->max_load_factor * hashtab->size;

printf("after\n");

C:\devel\pdos\pdmake>pdmake --help
before

C:\devel\pdos\pdmake>

Did my program work?

Looks fine to me. No error message.

BFN. Paul.

[Bart]

On 01/09/2023 00:12, Kaz Kylheku wrote:
> On 2023-08-31, Bart <b...@freeuk.com> wrote:

> The tools won't do that by default; that would break them for everyone
> who relies on them to behave in their default way.

That's tool1.exe

>> Whereas I can build all my language projects from one location, for example:
>>
>> c:\demo>mm \ax\aa
>> Compiling \ax\aa.m------ to \ax\aa.exe
>
> gcc does this for object files:
>
> gcc path/to/foo.c -c
>
> produces path/to/foo.o.

Not on my machine. This is why I raised the issue.

Using gcc -c, the .o file is always placed in the "." path, irrespective
of the path prepended to the input filename.

That's how it behaves on Windows and under WSL.

>> c:\demo>mm \cx\cc
>> Compiling \cx\cc.m------ to \cx\cc.exe
>>
>> c:\demo>mm \qx\qq
>> Compiling \qx\qq.m------ to \qx\qq.exe
>>
>> c:\demo>mm \mx\mm
>> Compiling \mx\mm.m------ to \mx\mm.exe
>
> That's just your preference, it would be better to have cc.exe, qe.exe
> and mm.exe right here in this directory instead of being buried in
> subdirectories.

(My normal process is to build within the development directory, and use
a script to move a production executable to where it normally lives.

The behaviour that you describe could result in multiple mm.exe files in
assorted locations, which is undesirable.

Because I mostly work on compilers, I may be testing this new compiler
on one within a different set of folders. I don't want the executables
from that one to contaminate any here, even if they have different names.)

> There are Makefiles that bury things that way; they are irksome.
> Hey, make worked; where is the program??? Ah, in src/output,
> whatever for ...

Oh, if only there was a way for the compiler to just tell you where it's
going to put the output!

>> And maybe, navigate
>> back to the start point when it's done?
>
> That's not necessary;

It might be if you decided to run the command again. But with a
different start location, who knows what might happen?

when a child process does chdir(), the parent
> is not affected. When you run a tool that changes directory, your
> current directory is not affected.
>
> I'm pretty sure Windows works that way too.

I find it hard to change the CWD programmatically, at least
persistently. But these are scripts where you can issue actual CD commands.

[Kaz Kylheku]

On 2023-09-01, Bart <b...@freeuk.com> wrote:
> Are you so averse to 'verbosity' then a one-line message reporting a
> failure cannot be tolerated?

I don't know about Keith, but I don't want to see "compilation failed",
bcause I want to see something else.

I want to see specific diagnostics, pinpointed to locations in the
file.

If there is nothing to diagnose, then the compilation should be
successful.

If there is something to diagnose, the failed message is redundant.
If all the diagnostics are warning: then we have success; if any
of them are error: then not.

What is your repro test case for a quiet gcc run that has failed?
(I missed it).

What I don't want is diagnostics on *success*:

C:\> copy hello.txt con
Hello
1 file(s) copied

Yikes. I said copy the content sof hello.txt to con, and it copied
that plus something else I didn't ask for.

[Kaz Kylheku]

On 2023-09-01, Paul Edwards <muta...@gmail.com> wrote:
> Real life example on Windows 10:
>
> printf("before\n");
> ggg = hashtab->max_load_factor * hashtab->size;
> printf("after\n");
>
> C:\devel\pdos\pdmake>pdmake --help
> before
>
> C:\devel\pdos\pdmake>
>
>
> Did my program work?
>
> Looks fine to me. No error message.

That's a garbage OS / shell problem.

A reasonable job control language must inform you if a job
terminateed abnormally ("abended" in old graybeard language).

You should never have to put in inane chatter into programs
just to confirm that they worked.

It's better to fix that in one place (the command interpreter)
rather than in millions of programs.

[Bart]

On 01/09/2023 02:09, Paul Edwards wrote:
> On Friday, September 1, 2023 at 8:44:20 AM UTC+8, Bart wrote:
>
>> You're sort of missing the point. Is it really that hard to do:
>>
>> puts("Compilation failed");
>> exit(1);
>
> That is already being done - an error message is printed
> when there is an error.
>
> What is not being done is:
>
> puts("Compilation succeeded");
> exit(0);
>
> So on Windows - if there was a crash - not a deliberate
> exit - you don't know if it was successful or not.

Where this is an issue: I can't tell whether a program has failed or
passed, I will put in such a message.

On my compilers, on a 20-year-old one it says:

Compilation Complete

On recent ones, a terminating message is not shown (or it is subtle,
like adding a full-stop when done, or it needs -v).

Because they usually finish instantly, I can tell if there has been a
crash because it takes a second or so to terminate.

> But if Windows had the ability to display "crashed", the
> same as that Unix option, you would know.

It used to say that; I've no idea why it doesn't do so now.

>
> P.S. I have replied to your email - please check your spam folder if
> you didn't receive it, or return the conversation to here if we are
> having communication issues.

OK.

[Keith Thompson]

Bart <b...@freeuk.com> writes:
> On 01/09/2023 00:46, Keith Thompson wrote:
>> Bart <b...@freeuk.com> writes:
>>> On 31/08/2023 23:07, Scott Lurndal wrote:
>> [...]
>>>> If it doesn't say anything, it worked. If it doesn't work it will
>>>> say something. If your really want to know what it's doing, use
>>>> -v.
>>>
>>> <Literally both face palms on face>
>>>
>>> If it doesn't say anything, it worked? Since Windows 10, a crashing
>>> program doesn't say anything; it silently fails.
>> [...]
>> If gcc fails, it returns a status that indicates failure. If you're
>> using a Bourne-like shell, you can examine the value of $?. In a
>> Windows command shell, `echo %errorlevel%`. In PowerShell, $? is True
>> or False, and $LASTEXITCODE is the status value.
>> I've configured bash to show me any non-zero exit value after
>> running a
>> command. I don't know whether you can do that on Windows.
>
> You're sort of missing the point.

No, I'm making a different point. I was *explaining* to you how gcc
behaves.

I don't think I've ever seen you learn something and be happy about it.
I find that bizarre.

> Is it really that hard to do:
>
> puts("Compilation failed");
> exit(1);
>
> rather than:
>
> exit(1);

No, of course it's not hard to do. gcc doesn't do that, but for
reasons that have nothing to do with any difficulty of implementing it.
And you're angry at me for not being angry about it.

I won't cause you further pain by trying to explain the reasons.

> Are you so averse to 'verbosity' then a one-line message reporting a
> failure cannot be tolerated?

No.

In another message in this thread, I wrote:

I acknowledge that you prefer tools to be verbose, and that you have
perfectly valid reasons to want a compiler to show what it's doing
and for a file copying program to print the name of each file as
it's copying it.

I believe you are capable of understanding that. You choose to pretend
that you don't.

> I find it bizarre that you like your programs so silent that you need
> to employ external means to find if they ran successfully or not!

I'm sure you do.

[...]

[Keith Thompson]

Kaz Kylheku <864-11...@kylheku.com> writes:
[...]

> gcc does this for object files:
>
> gcc path/to/foo.c -c
>
> produces path/to/foo.o.
>
> The default executable is a.out, or else whatever you pass to -o
> is taken verbatim.

Can you double check that? Here's what I get on my system
(Ubuntu 22.04.3, gcc 11.4.0).

$ find . -type f
./path/to/foo.c
$ gcc path/to/foo.c -c
$ find . -type f
./path/to/foo.c
./foo.o
$

[Malcolm McLean]

On Friday, 1 September 2023 at 00:32:03 UTC+1, Kaz Kylheku wrote:
>
> Building other people's projects can suck. It sucks not just for
> Bart but for the rest of us who don't mind the defaults and conventions.
>
> FOSS projects are written by volunteers. They don't owe you anything,
> including a build system that works how you would like.
>
> It's sad that people do counterproductive things to their programs, like
> vandalize their build systems with Autoconf, just because that's what
> others have done and they read about it in some blog or tutorial.
>

Bart's basic complaint is right. It's too hard to build many projects, and
if the build system breaks, it's too hard to fix it. Or the build requires
an unacceptable installation of dependencies into your global workspace.

Generally big projects are OK. They are well maintained, and when people
complain of glitches in the build system, they are ironed out. But small
projects are very likely to have build issues.

[Paul Edwards]

On Thursday, August 31, 2023 at 10:43:25 PM UTC+8, Paul Edwards wrote:
> On Thursday, August 31, 2023 at 9:45:14 PM UTC+8, Bart wrote:
>
> > I realise the code generator on BCC is poor, and is buggy, which is why
> > I kept it as a private tool. (/My/ C code is very conservative; there it
> > works fine!)

> Ok, thanks. I'll see if I can rework the C code to be conservative.

It took a while, but I was successful:

https://sourceforge.net/p/pdos/gitcode/ci/master/tree/pdcc/cpplib/directs.c

/* cc64 goes haywire when this is a const - it treats the array as
a character array, so indexing goes up by 1 character instead of
element size. And sizeof returns the padded size, but the data
is stored without padding, which made diagnosing very difficult */
#ifdef __CC64__
#define const
#endif

static const directive directives[] = {
DIRECTIVE_TABLE
};

#ifdef __CC64__
#undef const
#endif


(note that this problem is unrelated to the problem I sent via
email - as far as I am aware, anyway).

BFN. Paul.

[David Brown]

And there is also an existing language called D. (I don't know if there
is a standard name for a D compiler.)

"bc" is also taken, otherwise that might have been a good choice.

[David Brown]

On 31/08/2023 21:26, Bart wrote:
> On 31/08/2023 18:36, David Brown wrote:

>> On 31/08/2023 16:30, Bart wrote:
>>> On 31/08/2023 13:36, David Brow
>

>>> But putting it in the current directory is sloppy. The current
>>> location can be arbitrary (or it might not be writeable):
>>>
>>>   c:\random>gcc \proj1\foo.c
>>>   c:\random>gcc \proj2\bar.c
>>>
>>

>> So don't do that.
>>
>> Make sure you are in the appropriate directory, then compile - or give
>> the output file name directly.  As I said, whatever default you use,
>> it will be wrong sometimes.
>
> But it's an extra thing that could be easily have been done right.
> Compilers work for us, not us for them.

Agreed.

A compiler that put its object files in the source directory would be
working against me, not for me.

Can you really not understand that people don't always agree with your
subjective opinions? Different people want different things. The
defaults you pick for your tool written by you and for you, are
(hopefully) going to work well for /you/. But that doesn't mean they
are of any use to anyone else.

Personally, I think it might be better to have fewer defaults at all for
this kind of thing. I'd be quite happy for a compiler to require an
explicit output file for compilation or linking (if it also handles
linking). Maybe when compiling, it would accept just an output
directory and have a default object file name. If there are no
defaults, there are no misunderstandings. (For the record, there are
lots of things that gcc has defaults for that I would prefer to be
explicit.)

>
> Suppose gcc decided to put the output files in a root directory, or some
> place where it would be a very bad idea to write or overwrite a file.
>

Suppose bcc had decided to put the output files in "c:\Program
Files\bcc\" ? Or better - suppose we /don't/ try to think about worse
choices that no tool has made?


> You can't just fob people off with 'So don't do that'; it needs to be
> fixed. But then neither can you further fob them off with: 'It's always
> done that, and further, one person in 1000, or some makefile from 1974,
> depends on it, so we can't change it, ever'.
>

Putting object files in the current directory is a useful default. It
won't suit everyone, but it will suit some people. And since almost
anyone who has an "everything in one directory" structure will be in
that directory when they run their compiler (or make, or whatever), it
would give the same effect as your compiler's default choice.

I really don't understand what you have against it - other than your
knee-jerk reaction of "gcc does it, therefore it must be terrible and I
must invent absurd situations to justify myself".

>
>>> Here, both compilations generate a.exe. But to cap that, both end up
>>> in c:\random; the second overwrites the first, something you might be
>>> unaware of.
>>

>> If you are not aware of that, you'll learn pretty quickly!
>
> It may not have crossed your mind, or if it had, your might assume that
> two distinct a.exe files were produced.
>

True. And you'll learn very quickly.

>>>
>>> If I do:

>>>
>>>   c:\random[gcc \proj1\foo.c
>>>   c:\random>gcc \proj2\bar.c
>>>

>>> then there are three differences from gcc:
>>>
>>>   (1) The executables are called foo.exe and bar.exe respectively
>>>   (2) They are written to their respective folders
>>>   (3) The compiler will report exactly what it is doing so there
>>>       are fewer surprises:
>>>
>>>       Compiling \proj1\foo.c to \proj2\foo.exe
>>>
>>> You can use -v with gcc, but it is not helpful!

>>
>> Nor is it helpful for the compiler to tell me what it is doing -
>
> If the compiler is doing multiple files, especially a slow compiler,
> then it is highly useful to know where it's up to, or what it's stuck on.

That is not my experience. And I thought the point of your compiler was
to be absurdly fast? Still, I've nothing against compilers giving such
messages - I just personally prefer not to see them, so I at least want
a way to hide them (without hiding useful messages). I have happily
used compilers with a "-quiet" flag in the makefile.

>
> But this seems to be a Linux thing: if I do 'cp *.c dest', then nothing
> is output, until you get the prompt back. So, did work, did it copy
> anything, was it one big file, or lots of small ones?

It certainly is a common Unix practice that you get told when things
failed, and sometimes when things worked, but rarely get told that the
program is about to do what you asked it to do. And in cases where more
information is useful, you use "-v".

So you can assume "cp *.c dest" worked - it did what you asked it to do.
You did not ask how many files there were, or how big they are - there
are other commands to do that.

Unix philosophy (which is not always followed) is for one program to do
one thing. "cp" copies files - if you want a listing of files, use "ls".

Windows philosophy (which is also not always followed) is for every
program to re-invent the wheel in a different way and do all sorts of
things, because there are no common practices, few common libraries, and
most stuff is closed source.

>
> If I do 'copy *.c test' on Windows, it shows each file copied, and it
> tells how many files were copied in all. The 'cp' command needs '-v' to
> force to show what it's doing.
>
> The defaults are backwards.

Then add "alias cp='cp -v'" to your .bashrc. Choice is a wonderful
thing. (And so is google, so that you don't need to remember the
details here.)

>
>> generally I know what it is doing - it is doing what I told it to do.
>> It is only if it can't do that (due to some error) that I want to be
>> told.
>>
>> Again, different defaults suit different uses and different people.
>> Plenty of gcc's defaults are inappropriate for me, and I think should
>> be different - but your compiler's defaults are no better.  You only
>> /think/ that your compiler's defaults are good, because they suit you
>> personally
>
> No, they make more sense for casual use from a command line for anybody.

I'm sorry, but you are simply wrong here - in /my/ opinion. Your
opinion is your own, but you do not speak for anyone but yourself.

>
>> Do you also have a "-quiet" option to hide non-essential messages?
>> That's also something I like in compilers and other tools, if it is
>> not the default - though again, preferences vary.
>
> Yes, I think it's -q. If a lot of files are being processed, then you
> might want to turn it off (or if timing, it can make a small difference).
>

Good. If I were using your compiler, I would add that to my makefile -
giving me the options I want rather than the defaults you like.

> However gcc's -v option generates 40 times as much output as my compiler
> without -q. So it's either far too verbose, or not enough.
>

I still don't see why a compiler should print out a line to say it is
compiling the file you asked it to compile. If I want that information,
I have it in the command I typed in. (Or I would have my makefile show
the command before it is run.)

As for "gcc -v" being verbose - yes, it certainly is. It's not
something I have often used. It provides a lot of information that can
vary between systems, which is occasionally useful to know about. (I
have, for example, used it to see the include search paths used in
embedded gcc toolchains.)

[David Brown]

On 01/09/2023 00:18, Bart wrote:
> On 31/08/2023 23:07, Scott Lurndal wrote:
>> Bart <b...@freeuk.com> writes:
>>> On 31/08/2023 18:36, David Brown wrote:
>>>
>>>> Nor is it helpful for the compiler to tell me what it is doing -
>>>
>>> If the compiler is doing multiple files, especially a slow compiler,
>>> then it is highly useful to know where it's up to, or what it's stuck
>>> on.
>>
>> $ ps -ef | grep gcc
>>
>>>
>>> But this seems to be a Linux thing: if I do 'cp *.c dest', then nothing
>>> is output, until you get the prompt back. So, did work, did it copy
>>> anything, was it one big file, or lots of small ones?
>>
>> If it doesn't say anything, it worked.  If it doesn't work it will
>> say something.   If your really want to know what it's doing, use
>> -v.
>
>
> <Literally both face palms on face>
>
> If it doesn't say anything, it worked?

Yes.

> Since Windows 10, a crashing
> program doesn't say anything; it silently fails.

A decent OS will tell you if something has crashed.

>
> And when there is a lot going on with gcc, you can get loads of warnings
> and other crap scrolling up the screen. So, was there an "error:" in
> there or not? I've no idea if it worked!

Fix the problems in your source code (or choice of flags to the
compiler) - if you are getting screenfuls of errors or warnings, it is
irrelevant whether an output file was generated or not.

I certainly fail to see how the situation would be improved by a message
at the start saying "Compiling hello.c to hello.o" !


When you have lots of errors or warnings like this, some suggestions are:

1. Use a terminal that lets you scroll back to the start. Try something
other than Window's amateur terminal - or at least, change the default
settings from tiny scroll buffer to something useful.

2. Pipe the output into "less" (or "more", if you are limited to
Window's own tools).

3. Use an editor or IDE from this century - then all your errors or
warnings will be shown in your source code, so that you go straight to
the problems.

4. Use "-fmax-errors=5" to stop after the first 5 errors, or
"-Wfatal-errors" to halt on any problems, or "-Werror" to make warnings
into errors (combine with "-fmax-errors="). These are all documented,
unsurprisingly, under "Options to Request or Suppress Warnings".

>
> I have to see if there is a recent .exe just created.
>
> Or sometimes I get a clue by there being a pause after the last message,
> meaning it's doing the rest of it.
>
> (Or maybe it's just crashed.)

You'll get a message if there is a crash.

>
> Or I have to supply options to tell it to stop after one error (I have
> to find it first).

See above. Or try google - it tends to be far more efficient than
whining and moaning.

>
> Or I have to capture the output twice (first with >, second after I've
> remembered it's 2>), so that I can use a text editor to search for
> "error:" strings.
>
> What an effing palaver.

What do you expect to get if you have lots of errors in your code? A
pat on the back and a Blue Peter badge?

>
> gcc is not the only program like that, but it seems typical of where it
> came from.
>
>
>>> The defaults are backwards.
>>
>> No.
>
> Delude yourself if you like.
>

I bet you were in the army cadets when you were a kid, and your mum
would watch the parade and tell people how everyone else is out of step
except for her little Bart. Is that why you refuse to acknowledge other
people think differently from you?

[Malcolm McLean]

On Friday, 1 September 2023 at 09:43:43 UTC+1, David Brown wrote:
>
> Putting object files in the current directory is a useful default. It
> won't suit everyone, but it will suit some people. And since almost
> anyone who has an "everything in one directory" structure will be in
> that directory when they run their compiler (or make, or whatever), it
> would give the same effect as your compiler's default choice.
>
> I really don't understand what you have against it - other than your
> knee-jerk reaction of "gcc does it, therefore it must be terrible and I
> must invent absurd situations to justify myself".
>

It was the old way of doing things.
Noways most people prefer the "out of tree build". Basically your valuable,
human-generated, human-meaningful source files go in one directory,
the object files and various other intermediates automatically generated by
tools are sequestrated in another directory.
The new way is in my view a lot better, but it does make it a bit more difficult
to set up tools like "make".

[David Brown]

On 31/08/2023 22:03, Bart wrote:
> On 31/08/2023 20:28, Kaz Kylheku wrote:

>> You don't want to be dropping binaries in the sae place where the
>> sources are located.
>>
>> *THAT* location may be read-only!
>
> The location that you invoke the compiler from may be read-only!

Yes - that is entirely true. That is why any choice of default here is
only going to suit some use-cases. That is why gcc's choice is not
perfect for everyone - just like /your/ choice is not perfect for everyone.

Can you still not understand what people are trying to tell you? Are
you so obsessed with screaming at everything that gcc and/or Linux does,
and screaming at everyone who uses them, that this has still not sunk in?

Defaults work in some cases, not others.


>
> I guess I'm an oddball. I routinely modify source files and write new
> EXEs in the same folder. What's the point of mucking about with a
> special folder just for the one EXE file?
>

You do realise that if you go to your source directory and use "gcc",
the default is to put the output files in that same directory, just like
if you use "bcc" ? So gcc's defaults work perfectly well for compiling
the way you want - all you need is to give a name for the exe file that
suits your preferences (it gets put in the directory you want).

[Bart]

On 01/09/2023 09:43, David Brown wrote:

> On 31/08/2023 21:26, Bart wrote:

> Putting object files in the current directory is a useful default.

'gcc -c' will do that if the input file is in the same current directory.

So if the current directory happens to be /abc, compiling hello.c will
produce /abc/hello.o from /abc/hello.c.

Everyone has been saying, do the build from inside the source directory.
They've also been saying don't put the object file in the source directory!

That means gcc breaks that rule by default. But look at this pattern:

Object file written to:

abc> gcc hello.c /abc/hello.o
abc> gcc /abc/hello.c /abc/hello.o
xyz> gcc /abc/hello.c /xyz/hello.o

This looks wrong.

> It
> won't suit everyone, but it will suit some people.  And since almost
> anyone who has an "everything in one directory" structure will be in
> that directory when they run their compiler (or make, or whatever), it
> would give the same effect as your compiler's default choice.
>
> I really don't understand what you have against it - other than your
> knee-jerk reaction of "gcc does it, therefore it must be terrible

Or "gcc does it, therefore it must be OK, and the model of how all
software must work"

If I give gcc 100 files to build, will it finish it in a few seconds, or
do I go and make a drink? Simply listing the same of each file will give
a useful indication of where it's up to and how until it's done.

Presumably, you can't see the point of those progress bars you see in GUIs?

> and I
> must invent absurd situations to justify myself".

I raised the issue because the OP did this:

cc64 -c -out:cclib/cclib.obj cclib/cclib.i

I assumed this was out of habit because other compilers required it, and
I double-checked mine.

Note that the current directory is not known in this posted fragment.
With bcc however, I KNOW that with:

bcc -c cclib/cclib.i

the .obj file will be cclib/cclib.obj, in the same directory, as that is
the clear intent. But with:

gcc -c cclib/cclib.i

I don't where the .o file will be; I will guess it is one directory
above. If the path was /cclib/cclib.i, then it could be anywhere in the
file system.

> I still don't see why a compiler should print out a line to say it is
> compiling the file you asked it to compile.  If I want that information,
> I have it in the command I typed in.

It is confirming the input file, output file, the extensions that will
be used, and the operations that can be done.

The output file is certainly not clear from what you typed:

gcc -shared -oprog prog.c

On Windows, this writes prog.exe, NOT prog.dll that you might expect.

The destination is not clear from what you typed:

root@DESKTOP-11:/mnt/c/c# gcc /abc/hello.c

The destination here is derived from the CWD, and will be
/mnt/c/c/hello.o. Not what you typed.

The operation being done is not clear from what you typed as that
depends on 'options' file:

gcc @options hello.c

The files being compiled are not always clear from what you typed:

gcc *.c
gcc @input

There could 1 file, or 1000 files. You're really not curious as to what
it's doing?

I've noticed that ./configure and makefile scripts are not usually
silent; quite the opposite! apt-get install likes to give a running
commentary too.

So verbosity is good when a tool is verbose. Verbosity is bad when a
tool usually says nothing. This sounds very much like defending or
excusing all the tools you use against ANY sort or criticism.

Summary:

gcc prog.c producing 0 bytes of output: Great
gcc prog.c -v producing 5000 bytes of output: Great
bcc prog producing 25 bytes of output: Terrible!

Have I summed up your view correctly?

[Bart]

On 01/09/2023 10:10, David Brown wrote:
> On 01/09/2023 00:18, Bart wrote:


>> And when there is a lot going on with gcc, you can get loads of
>> warnings and other crap scrolling up the screen. So, was there an
>> "error:" in there or not? I've no idea if it worked!
>
> Fix the problems in your source code (or choice of flags to the
> compiler) - if you are getting screenfuls of errors or warnings, it is
> irrelevant whether an output file was generated or not.

We are talking about compilers like gcc where you make up your own rules
as to show strictly you want your program treated:

gcc prog.c zero warnings, writes .exe
gcc @options prog.c 10000 warnings, but it still writes .exe
gcc @options prog.c 10000 warning and 1 error, no .exe

In the first two cases, the .exe runs fine. I've just asked it to be
more picky. It's telling the difference between the last two that is the
problem. The one error is buried in those warnings. There is no summary
at the end.

This is where you need to use half a dozen ways to figure out:

DID IT WORK?

DID IT NOT WORK?

Because the compiler, aften 30,000 lines of output, decides it would be
too verbose to print a one-line summary.

With bcc, in order to more easily detect a silent crash, I added a
confirmation message, but it is subtle (it was for my use).

bcc prog.c
Compiling prog.c to prog.exe

When it finished it adds a full-stop:

Compiling prog.c to prog.exe.

If there was an error, it will report the error and stop. There is only
the one error, and there are no warnings.

With lccwin32, if there are any errors or warnings, it will summarise as:

2 errors, 0 warnings

It's really not hard.

[David Brown]

On 01/09/2023 13:01, Bart wrote:
> On 01/09/2023 10:10, David Brown wrote:
>> On 01/09/2023 00:18, Bart wrote:
>
>
>>> And when there is a lot going on with gcc, you can get loads of
>>> warnings and other crap scrolling up the screen. So, was there an
>>> "error:" in there or not? I've no idea if it worked!
>>
>> Fix the problems in your source code (or choice of flags to the
>> compiler) - if you are getting screenfuls of errors or warnings, it is
>> irrelevant whether an output file was generated or not.
>
> We are talking about compilers like gcc where you make up your own rules
> as to show strictly you want your program treated:
>
>  gcc prog.c              zero warnings, writes .exe
>  gcc @options prog.c     10000 warnings, but it still writes .exe
>  gcc @options prog.c     10000 warning and 1 error, no .exe
>
> In the first two cases, the .exe runs fine. I've just asked it to be
> more picky. It's telling the difference between the last two that is the
> problem. The one error is buried in those warnings. There is no summary
> at the end.
>
> This is where you need to use half a dozen ways to figure out:
>
>   DID IT WORK?
>
>   DID IT NOT WORK?

I think a more interesting question here is "Do you want it to work?"
And the answer, of course, is "No" - you don't want it to work, you
don't want to know how to get it to work, or how to find out what went
wrong. If you ever listened to advice, suggestions or help, or tried to
make things work rather than working so hard to get failures, you might
accidentally discover that gcc is usable after all. And that would be
just terrible for you.

You have such a strong emotional investment in the idea that you are
always right, all your opinions are the best, your languages and tools
are perfect, while all other languages and tools are utterly useless and
all other opinions are completely wrong, that contradictory evidence
would be devastating. It must be very difficult for you, being so fragile.

[David Brown]

On 01/09/2023 11:17, Malcolm McLean wrote:
> On Friday, 1 September 2023 at 09:43:43 UTC+1, David Brown wrote:
>>
>> Putting object files in the current directory is a useful default. It
>> won't suit everyone, but it will suit some people. And since almost
>> anyone who has an "everything in one directory" structure will be in
>> that directory when they run their compiler (or make, or whatever), it
>> would give the same effect as your compiler's default choice.
>>
>> I really don't understand what you have against it - other than your
>> knee-jerk reaction of "gcc does it, therefore it must be terrible and I
>> must invent absurd situations to justify myself".
>>
> It was the old way of doing things.

It is also the current way of doing things for smaller projects. And
out of tree builds are not new.

People prefer different ways of arranging their builds, which is
absolutely fine.

> Noways most people prefer the "out of tree build".

Some do, some don't, and some do for some projects and not others.
Unless you have the statistics to prove it, please don't try to speak
for "most people".

I also usually prefer out-of-tree builds for bigger projects (but I find
in-tree builds convenient for small single-file programs). But "you and
I" does not mean "most people".

> Basically your valuable,
> human-generated, human-meaningful source files go in one directory,
> the object files and various other intermediates automatically generated by
> tools are sequestrated in another directory.

> The new way is in my view a lot better, but it does make it a bit more difficult
> to set up tools like "make".

It's not hard at all. You do have to consider it in the makefile, but I
would not classify it as "difficult".

[David Brown]

On 01/09/2023 12:35, Bart wrote:
> On 01/09/2023 09:43, David Brown wrote:
>> On 31/08/2023 21:26, Bart wrote:
>
>> Putting object files in the current directory is a useful default.
>
> 'gcc -c' will do that if the input file is in the same current directory.
>
> So if the current directory happens to be /abc, compiling hello.c will
> produce /abc/hello.o from /abc/hello.c.
>
> Everyone has been saying, do the build from inside the source directory.
> They've also been saying don't put the object file in the source directory!

Really? Everyone?

Do you bother to read the posts here, or do you just cherry-pick a few
snippets that you can complain about?

I have said /many/ times that sometimes people what out-of-tree builds,
and sometimes they want in-tree builds, and that there are pros and cons
of each. Generally you are better with out-of-tree builds for big
projects, while it can be convenient with in-tree builds for small projects.

Will you please acknowledge that you have read that paragraph, and that
you understand it, so that we can go on?

>
> That means gcc breaks that rule by default. But look at this pattern:
>
>                               Object file written to:
>
>   abc> gcc hello.c            /abc/hello.o
>   abc> gcc /abc/hello.c       /abc/hello.o
>   xyz> gcc /abc/hello.c       /xyz/hello.o
>
> This looks wrong.

It only looks wrong because you make it look wrong. Every time, the
file is written to "./hello.o". Simple and consistent. And if that's
not what you want, then specify the output file that you /do/ want. (Or
write a wrapper. Or use make. Or do one of a dozen alternatives that
get you what you wanted, rather than bursting a blood vessel and blaming
the wrong people for your own wilful and self-created problems.)

>
>> It won't suit everyone, but it will suit some people.  And since
>> almost anyone who has an "everything in one directory" structure will
>> be in that directory when they run their compiler (or make, or
>> whatever), it would give the same effect as your compiler's default
>> choice.
>>
>> I really don't understand what you have against it - other than your
>> knee-jerk reaction of "gcc does it, therefore it must be terrible
>
> Or "gcc does it, therefore it must be OK, and the model of how all
> software must work"

No one has /ever/ said anything of the sort. You are tilting at
windmills again.

>
> If I give gcc 100 files to build, will it finish it in a few seconds, or
> do I go and make a drink? Simply listing the same of each file will give
> a useful indication of where it's up to and how until it's done.

I suggest you don't bother with gcc - just go and have that drink.
Maybe you'll feel better.

>
> Presumably, you can't see the point of those progress bars you see in GUIs?

Presumably you are making stuff up again.

I would suggest that the answer to your problem is that you should not
call gcc on 100 files - the normal practice is to use make (or something
similar) to call gcc a hundred times on one file at a time, taking
advantage of modern multi-core machines, skipping unnecessary re-builds,
and generally being more efficient. (And also printing out "Compiling
file.c" lines if you want.) But I'll keep quite, because I know you
don't want a useful suggestion that would hinder you in your god-given
right to be the pain in your own arse.

>
> Have I summed up your view correctly?
>

No, but that is only to be expected from you.

[Richard Harnden]

On 01/09/2023 12:01, Bart wrote:
> On 01/09/2023 10:10, David Brown wrote:
>> On 01/09/2023 00:18, Bart wrote:
>
>
>>> And when there is a lot going on with gcc, you can get loads of
>>> warnings and other crap scrolling up the screen. So, was there an
>>> "error:" in there or not? I've no idea if it worked!
>>
>> Fix the problems in your source code (or choice of flags to the
>> compiler) - if you are getting screenfuls of errors or warnings, it is
>> irrelevant whether an output file was generated or not.
>
> We are talking about compilers like gcc where you make up your own rules
> as to show strictly you want your program treated:
>
>  gcc prog.c              zero warnings, writes .exe
>  gcc @options prog.c     10000 warnings, but it still writes .exe
>  gcc @options prog.c     10000 warning and 1 error, no .exe

Don't worry about 10,000 warnings/errors; Fix the first one, and
recompile. Rinse/Repeat.

[Malcolm McLean]

On Friday, 1 September 2023 at 11:36:09 UTC+1, Bart wrote:
>
> Everyone has been saying, do the build from inside the source directory.
> They've also been saying don't put the object file in the source directory!
>

You don't want human-generated, human-readable, and therefore quite
valuable files mixed with computer-generated intermediate files which
are worthless except as intermediates, and usually only on that platform.

But the normal answer is to create a "build" directory under the root of
the source directory which you wrote yourself, or downloaded. Then all
the compiler products and other cruft goes in there. You don't put anything
of much value in the "build" directory, and if something goes badly wrong,
often something to try is to delete it and start a clean rebuild.

>
> That means gcc breaks that rule by default. But look at this pattern:
>
> Object file written to:
>
> abc> gcc hello.c /abc/hello.o
> abc> gcc /abc/hello.c /abc/hello.o
> xyz> gcc /abc/hello.c /xyz/hello.o
>
> This looks wrong.
>

It's not too bad.

You download

whizzyproject
..................documents
..................source

you make a new directory, build, under whizzyproject

build> gcc ../source/*.c

will create a.out in the build directory.

>
> If I give gcc 100 files to build, will it finish it in a few seconds, or
> do I go and make a drink? Simply listing the same of each file will give
> a useful indication of where it's up to and how until it's done.
>

Who knows. But it's not really a useful indication because C source files
can vary wildly in length and complexity. The optimisation problem reduces
to the halting problem, after all.
However I agree that it;s nice to have a pacifier. Also, if the compiler crashes
out or hangs whilst compiling barts_special_file.c, then it helps that its last
message was "compiling barts_speciaL_file.c".

[Bart]

You're joking, right? Maybe some of them I need to do something about,
but most of them are irrelevant:

cc.c:5363:5: warning: ISO C forbids initialization between function
pointer and 'void *' [-Wpedantic]
5363 | &cc_genasm$stropndx,
| ^

You can't turn a 64-bit void* pointer on x64 into a 64-bit function
pointer? **** off!


Or unused labels. Or unused parameters (in a suite of functions that
must share the same set).

How do I discover the important ones?

This is for generated code. The fact is, WHATEVER I do, somebody can
just ramp up the options further to make it show a diagnostic.

The simple solution is for me to stipulate the compile options, or for
me to control the process (by my backend invoking the compiler directly).

Apparently, you can do that with gcc: it's one positive, if bizarre,
aspect of it.

It's bizarre because *I*, as user, have to tell an actual C compiler how
to compile my code, what to treat seriously, and what to disregard.

In other words, I have to do half its job for it. Including finding out
whether it's has succeeded!

[Bart]

On 01/09/2023 12:39, David Brown wrote:
> On 01/09/2023 12:35, Bart wrote:

>>                                Object file written to:
>>
>>    abc> gcc hello.c            /abc/hello.o
>>    abc> gcc /abc/hello.c       /abc/hello.o
>>    xyz> gcc /abc/hello.c       /xyz/hello.o
>>
>> This looks wrong.
>
> It only looks wrong because you make it look wrong.  Every time, the
> file is written to "./hello.o".  Simple and consistent.

And dangerous, since "." is variable. And it can't be consistent since
that third line writes it to xyz not abc. With bcc (excuse use of /
rather than \):


abc> bcc hello.c /abc/hello.obj
abc> bcc /abc/hello.c /abc/hello.obj
xyz> bcc /abc/hello.c /abc/hello.obj

Position-independent compilation!

>> Or "gcc does it, therefore it must be OK, and the model of how all
>> software must work"
>
> No one has /ever/ said anything of the sort.  You are tilting at
> windmills again.
>
>>
>> If I give gcc 100 files to build, will it finish it in a few seconds,
>> or do I go and make a drink? Simply listing the same of each file will
>> give a useful indication of where it's up to and how until it's done.
>
> I suggest you don't bother with gcc - just go and have that drink. Maybe
> you'll feel better.
>
>>
>> Presumably, you can't see the point of those progress bars you see in
>> GUIs?
>
> Presumably you are making stuff up again.

And you're not answering the question. Progress bars obviously ARE
useful, but not for a compiler?

>> Have I summed up your view correctly?
>>
>
> No, but that is only to be expected from you.

Have I then summed up the capabilities of gcc correctly?

That it either it says nothing, or spouts pages of nonsense.

But then, you don't really care do you, as you mainly use such compilers
from inside a script, where its behaviour is carefully orchestrated.

So the actual problems others experience are no skin off your nose.

I'm glad that my own product is friendlier, helps with such problems,
and is amenable to being tweaked according to suggestions.

[David Brown]

If you ever decide you want to learn C, you can always ask here for help.

The same applies if you ever decide you want to learn how to use gcc
(though of course some people here will say it is off-topic).

All that will be asked of you, is that you ask politely and listen to
the answers, and do your best to understand. It's not actually very hard.

[Richard Harnden]

On 01/09/2023 13:39, Bart wrote:
> On 01/09/2023 13:08, Richard Harnden wrote:
>> On 01/09/2023 12:01, Bart wrote:
>>> On 01/09/2023 10:10, David Brown wrote:
>>>> On 01/09/2023 00:18, Bart wrote:
>>>
>>>
>>>>> And when there is a lot going on with gcc, you can get loads of
>>>>> warnings and other crap scrolling up the screen. So, was there an
>>>>> "error:" in there or not? I've no idea if it worked!
>>>>
>>>> Fix the problems in your source code (or choice of flags to the
>>>> compiler) - if you are getting screenfuls of errors or warnings, it
>>>> is irrelevant whether an output file was generated or not.
>>>
>>> We are talking about compilers like gcc where you make up your own
>>> rules as to show strictly you want your program treated:
>>>
>>>   gcc prog.c              zero warnings, writes .exe
>>>   gcc @options prog.c     10000 warnings, but it still writes .exe
>>>   gcc @options prog.c     10000 warning and 1 error, no .exe
>>
>> Don't worry about 10,000 warnings/errors; Fix the first one, and
>> recompile.  Rinse/Repeat.
>
> You're joking, right? Maybe some of them I need to do something about,
> but most of them are irrelevant:

No. 10,000 warnings is ridiculus.

>
> cc.c:5363:5: warning: ISO C forbids initialization between function
> pointer and 'void *' [-Wpedantic]
>  5363 |     &cc_genasm$stropndx,
>       |     ^
>
> You can't turn a 64-bit void* pointer on x64 into a 64-bit function
> pointer? **** off!

You could use actual function pointers that have the correct signature?
You don't really call every function thru one single void*?

>
>
> Or unused labels. Or unused parameters (in a suite of functions that
> must share the same set).

So, shut the warning up. Otherwise it's just noise.
Most people say:
(void) unused_var;

>
> How do I discover the important ones?

By fixing the unimportant ones.

>
> This is for generated code. The fact is, WHATEVER I do, somebody can
> just ramp up the options further to make it show a diagnostic.

Maybe fix the generator to produce correct code in the first place?

[David Brown]

I presumed your question was rhetorical. Were you really asking
something that stupid? (And that was a rhetorical question.)

>>> Have I summed up your view correctly?
>>>
>>
>> No, but that is only to be expected from you.
>
> Have I then summed up the capabilities of gcc correctly?

No.

>
> That it either it says nothing, or spouts pages of nonsense.

No.

>
> But then, you don't really care do you, as you mainly use such compilers
> from inside a script, where its behaviour is carefully orchestrated.

No.

>
> So the actual problems others experience are no skin off your nose.

No.

>
> I'm glad that my own product is friendlier, helps with such problems,
> and is amenable to being tweaked according to suggestions.
>

No.

Were there more inaccuracies you want to make up? Any time you want to
change from rant mode to listen mode, just let me know.

[Ben Bacarisse]

Bart <b...@freeuk.com> writes:

> On 01/09/2023 13:08, Richard Harnden wrote:
>> On 01/09/2023 12:01, Bart wrote:

>>> We are talking about compilers like gcc where you make up your own rules
>>> as to show strictly you want your program treated:
>>>
>>>   gcc prog.c              zero warnings, writes .exe
>>>   gcc @options prog.c     10000 warnings, but it still writes .exe
>>>   gcc @options prog.c     10000 warning and 1 error, no .exe

Which would you choose as the one and only behaviour?

>> Don't worry about 10,000 warnings/errors; Fix the first one, and
>> recompile.  Rinse/Repeat.
>
> You're joking, right? Maybe some of them I need to do something about, but
> most of them are irrelevant:
>
> cc.c:5363:5: warning: ISO C forbids initialization between function pointer
> and 'void *' [-Wpedantic]
> 5363 | &cc_genasm$stropndx,
> | ^
>
> You can't turn a 64-bit void* pointer on x64 into a 64-bit function
> pointer?

You asked for the program to be checked 'pedantically' and now you are
complaining about that. If you don't want to know if your code violates
any of C's rules, why ask?

> Or unused labels. Or unused parameters (in a suite of functions that must
> share the same set).
>
> How do I discover the important ones?

It's up to you. That's the whole point. When I was porting code to a
machine with distinct code and data address formats, I would have loved
a warning like the one above, but the C compiler was not that helpful.
Only you know if you want your code to be highly portable or not; gcc
can't possibly know.

> This is for generated code. The fact is, WHATEVER I do, somebody can just
> ramp up the options further to make it show a diagnostic.

Is that true? #pragma GCC diagnostic "-Wno-xxxx" lines are not
overruled by command line warning options, but there may be a way to
force these to be ignored.

Anyway, why do you mind? The person ramping up the options is probably
doing so for some reason, but even it's just for fun of it, it's on
them.

--
Ben.

[Bart]

On 01/09/2023 14:53, Ben Bacarisse wrote:
> Bart <b...@freeuk.com> writes:
>
>> On 01/09/2023 13:08, Richard Harnden wrote:
>>> On 01/09/2023 12:01, Bart wrote:
>
>>>> We are talking about compilers like gcc where you make up your own rules
>>>> as to show strictly you want your program treated:
>>>>
>>>>   gcc prog.c              zero warnings, writes .exe
>>>>   gcc @options prog.c     10000 warnings, but it still writes .exe
>>>>   gcc @options prog.c     10000 warning and 1 error, no .exe
>
> Which would you choose as the one and only behaviour?
>
>>> Don't worry about 10,000 warnings/errors; Fix the first one, and
>>> recompile.  Rinse/Repeat.
>>
>> You're joking, right? Maybe some of them I need to do something about, but
>> most of them are irrelevant:
>>
>> cc.c:5363:5: warning: ISO C forbids initialization between function pointer
>> and 'void *' [-Wpedantic]
>> 5363 | &cc_genasm$stropndx,
>> | ^
>>
>> You can't turn a 64-bit void* pointer on x64 into a 64-bit function
>> pointer?
>
> You asked for the program to be checked 'pedantically' and now you are
> complaining about that. If you don't want to know if your code violates
> any of C's rules, why ask?

This is what happened in 2014 when I first posted some generated C code
here. People would apply all sorts of advanced warning levels.

But was there an actual bug in my program or not? If there was, why
wasn't it caught with 'gcc prog.c' and why did it proceed to generate an
executable?

(The object/function pointer issue wasn't of great interest. In both the
source language and known targets the conversion (actually, a no-op) is
well-defined. Only some C compilers get uppity about it.

There might have reason to do so on some exotic architecture, but then,
you can get around it by a double-conversion via an intermediate
integer, then those reasons appear to go out the window.

My generated code can also contains lots of usused labels. I'm sure that
one is not dangerous. But if people are applying their own compile
options, they can also apply the ones to shut up those warnings.)

>> Or unused labels. Or unused parameters (in a suite of functions that must
>> share the same set).
>>
>> How do I discover the important ones?
>
> It's up to you. That's the whole point. When I was porting code to a
> machine with distinct code and data address formats, I would have loved
> a warning like the one above, but the C compiler was not that helpful.
> Only you know if you want your code to be highly portable or not; gcc
> can't possibly know.

Then it needs a -Wportable check.

>> This is for generated code. The fact is, WHATEVER I do, somebody can just
>> ramp up the options further to make it show a diagnostic.
>
> Is that true? #pragma GCC diagnostic "-Wno-xxxx" lines are not
> overruled by command line warning options, but there may be a way to
> force these to be ignored.

Those don't always work. At least this doesn't:

#pragma GCC diagnostic ignored "-Wbuiltin-declaration-mismatch"

It works on Windows gcc but not WSL gcc.

In any case I would now stipulate the essential options, leaving only
ones like -o and -O to the user.

> Anyway, why do you mind? The person ramping up the options is probably
> doing so for some reason, but even it's just for fun of it, it's on
> them.

It's an example of gcc hiding a potential needle in a haystack of
warnings and notes. Was there anything important in there like an actual
'error:' line?

[David Brown]

On 01/09/2023 15:32, Richard Harnden wrote:
> On 01/09/2023 13:39, Bart wrote:
>> On 01/09/2023 13:08, Richard Harnden wrote:
>>> On 01/09/2023 12:01, Bart wrote:
>>>> On 01/09/2023 10:10, David Brown wrote:
>>>>> On 01/09/2023 00:18, Bart wrote:
>>>>
>>>>
>>>>>> And when there is a lot going on with gcc, you can get loads of
>>>>>> warnings and other crap scrolling up the screen. So, was there an
>>>>>> "error:" in there or not? I've no idea if it worked!
>>>>>
>>>>> Fix the problems in your source code (or choice of flags to the
>>>>> compiler) - if you are getting screenfuls of errors or warnings, it
>>>>> is irrelevant whether an output file was generated or not.
>>>>
>>>> We are talking about compilers like gcc where you make up your own
>>>> rules as to show strictly you want your program treated:
>>>>
>>>>   gcc prog.c              zero warnings, writes .exe
>>>>   gcc @options prog.c     10000 warnings, but it still writes .exe
>>>>   gcc @options prog.c     10000 warning and 1 error, no .exe
>>>
>>> Don't worry about 10,000 warnings/errors; Fix the first one, and
>>> recompile.  Rinse/Repeat.
>>
>> You're joking, right? Maybe some of them I need to do something about,
>> but most of them are irrelevant:
>
> No.  10,000 warnings is ridiculus.

Yes. It's because he does silly things (like using "void *" for
function pointers), and because he views warnings as all or nothing -
for Bart, it's either "gcc" or "gcc -Wall -Wextra", just as optimisation
is always either "-O0" or "-O3". Taking advice, reading manuals, or
knowing what he is doing are not his specialities.

>
>>
>> cc.c:5363:5: warning: ISO C forbids initialization between function
>> pointer and 'void *' [-Wpedantic]
>>   5363 |     &cc_genasm$stropndx,
>>        |     ^
>>
>> You can't turn a 64-bit void* pointer on x64 into a 64-bit function
>> pointer? **** off!
>
> You could use actual function pointers that have the correct signature?

He has been told countless times that, at the very least, "void*(void)"
would be hugely better.

> You don't really call every function thru one single void*?

Yes, he converts pretty much everything to "void*".

>
>>
>>
>> Or unused labels. Or unused parameters (in a suite of functions that
>> must share the same set).

In C23, unused parameters can be left unnamed - though apparently that
is an abomination in Bart's eyes.

>
> So, shut the warning up.  Otherwise it's just noise.
> Most people say:
> (void) unused_var;

Or use -Wno-unused-parameters -Wno-unused-labels, etc.

Or use #pragma GCC diagnostic ignored "-Wunused".

Or stop generating unused labels.

There are plenty of possibilities.

>
>>
>> How do I discover the important ones?
>
> By fixing the unimportant ones.
>
>>
>> This is for generated code. The fact is, WHATEVER I do, somebody can
>> just ramp up the options further to make it show a diagnostic.
>
> Maybe fix the generator to produce correct code in the first place?

And if the generator produces things like extra unused labels (it's not
uncommon), it could also generate pragmas to disable those warnings even
if the user had enabled them at the command line.

It would also make a great deal of sense to have pragmas for "-fwrapv"
and "-fno-strict-aliasing", since Bart's code generator requires these.

[Kaz Kylheku]

On 2023-09-01, Malcolm McLean <malcolm.ar...@gmail.com> wrote:
> On Friday, 1 September 2023 at 00:32:03 UTC+1, Kaz Kylheku wrote:
>>
>> Building other people's projects can suck. It sucks not just for
>> Bart but for the rest of us who don't mind the defaults and conventions.
>>
>> FOSS projects are written by volunteers. They don't owe you anything,
>> including a build system that works how you would like.
>>
>> It's sad that people do counterproductive things to their programs, like
>> vandalize their build systems with Autoconf, just because that's what
>> others have done and they read about it in some blog or tutorial.
>>
> Bart's basic complaint is right.

It is off topic and misdirected, though.

> It's too hard to build many projects, and

That's the fault of those projects, whose maintainers don't read this
newsgroup, and wouldn't change anything if they did.

So the complaining is completely useless.

It's like joining a cooking club, to complain about restaurant prices,
or the design of mixers and spatulas.

Probably a few regulars here work on some open source projects that
Bart might find hard to build.

Without a

- comphrehensive, realistic proposal;

- accompanied by a patch;

- that works on all supported platforms;

- and can be easily extended to new platforms;

- and is demonstrably better than the current system;

I wouldn't lift a finger. Fixing a build system is just risk that's
not even in the program. Breaking builds will make your program look
immature; possibly a deal breaker for a prospective user.

--
TXR Programming Language: http://nongnu.org/txr
Cygnal: Cygwin Native Application Library: http://kylheku.com/cygnal
Mastodon: @Kazi...@mstdn.ca

[Kaz Kylheku]

On 2023-09-01, Bart <b...@freeuk.com> wrote:
> On 01/09/2023 09:43, David Brown wrote:
>> On 31/08/2023 21:26, Bart wrote:
>
>> Putting object files in the current directory is a useful default.
>
> 'gcc -c' will do that if the input file is in the same current directory.
>
> So if the current directory happens to be /abc, compiling hello.c will
> produce /abc/hello.o from /abc/hello.c.

You are right. I didn't even notice that or forgot about it all these
years. -c is only used in very trivial makefiles.

The built-in make recipe doesn't use it; it uses -o so that if you say,

obj/foo.o: src/foo.c

it works fine. According to the gcc man page, I would think that
-c turns src/foo.c into src/foo.o.

Quote

By default, the object file name for a source file is made by
replacing the suffix .c, .i, .s, etc., with .o.

That's literally saying src/foo.c becomes src/foo.o. If
src/foo.c becomes foo.o, then the way to describe it is:

By default, the object file name for a source file is made by
taking the base name of the source file, removing any directory path
components, and replacing the suffix .c, .i, .s, etc., with .o.

> Everyone has been saying, do the build from inside the source directory.

More generally, you do the build from a build directory. That is almost
tautological. If you're building there, it's a build directory.

It's okay for the build directory to be the source directory.

Many FOSS projects support both modes: you can build in the source
directory, or you can create a separate build directory and configure
from there and build from there.

(AutoConf projects are like this, ideally. Some maintainers don't test
building in a separate directory, and also do something clever which
breaks it. Downstream distro packagers then work around it somehow,
without submitting a fix upstream.)

> They've also been saying don't put the object file in the source directory!

David pointed out advantages in not doing that, even if the project is
being built from within its source tree (not in a separate
build directory). This is not some hard and fast rule, though.

> That means gcc breaks that rule by default. But look at this pattern:

> Object file written to:
>
> abc> gcc hello.c /abc/hello.o
> abc> gcc /abc/hello.c /abc/hello.o
> xyz> gcc /abc/hello.c /xyz/hello.o
>
> This looks wrong.

Yes; so people who write their own build script or use their own make
recipe for .c to .o instead of the built-in one, will soon discover that
it isn't doing what they want. They will stop relyin gon using -c
without -o, one way or another: fix their script, fix their custom build
recipe, or use the built-in one.

[Kaz Kylheku]

On 2023-09-01, Bart <b...@freeuk.com> wrote:

> On 01/09/2023 10:10, David Brown wrote:
>> On 01/09/2023 00:18, Bart wrote:
>
>
>>> And when there is a lot going on with gcc, you can get loads of
>>> warnings and other crap scrolling up the screen. So, was there an
>>> "error:" in there or not? I've no idea if it worked!
>>
>> Fix the problems in your source code (or choice of flags to the
>> compiler) - if you are getting screenfuls of errors or warnings, it is
>> irrelevant whether an output file was generated or not.
>
> We are talking about compilers like gcc where you make up your own rules
> as to show strictly you want your program treated:
>
> gcc prog.c zero warnings, writes .exe
> gcc @options prog.c 10000 warnings, but it still writes .exe
> gcc @options prog.c 10000 warning and 1 error, no .exe

Firstly, gcc is a front end to multiple languages, including multiple
dialects to C. Some things which are fine in one dialect are errors
in another.

Everything you've ever done on any of your own compilers that was
not a pure refactoring or code cleanup change, everything,
always created a new dialect in which something worked that
previously did not work, and for which a test case could be written
which works with the changed compiler and fails with the previous
one before the change.

You can also tweak the diagnosis rules in GCC, so that something that is
a warning can be treated as a fatal error.

Users want this, and you will not pry it out of their hands.

What have you ever done in any of your compilers to support a user
whose code base uses your language, but from five years ago?

[Bart]

On 01/09/2023 14:32, Richard Harnden wrote:

> On 01/09/2023 13:39, Bart wrote:

>> You're joking, right? Maybe some of them I need to do something about,
>> but most of them are irrelevant:
>
> No.  10,000 warnings is ridiculus.
>
>>
>> cc.c:5363:5: warning: ISO C forbids initialization between function
>> pointer and 'void *' [-Wpedantic]
>>   5363 |     &cc_genasm$stropndx,
>>        |     ^
>>
>> You can't turn a 64-bit void* pointer on x64 into a 64-bit function
>> pointer? **** off!
>
> You could use actual function pointers that have the correct signature?
> You don't really call every function thru one single void*?



>
>>
>>
>> Or unused labels. Or unused parameters (in a suite of functions that
>> must share the same set).
>
> So, shut the warning up.  Otherwise it's just noise.
> Most people say:
> (void) unused_var;

I don't want to, and I shouldn't need to.

Here I'm using C as a portable assembler. In assembly, you don't need to
care about unused labels, unused parameters, or having a function
pointer in the same 64-bit register as an integer.

Generating C is supposed to make some things easier. It's not supposed
to make things harder!

If I compile my generated C with any of:

bcc prog
tcc prog.c
gcc prog.c -oprog

it works perfectly.

Unless there's actually something wrong with prog.c. In that case:

* Why doesn't gcc show any errors?
* Why not even warnings?
* Why is it generating an executable?

If the famous gcc thinks my program is OK, then that suits me fine.

If interpreting a 64-bit address as a function rather than object
pointer is such a no-no, then where's the hard error?

WHY is it letting such a serious infringement through?

[Ben Bacarisse]

Bart <b...@freeuk.com> writes:

> On 01/09/2023 14:53, Ben Bacarisse wrote:
>> Bart <b...@freeuk.com> writes:
>>
>>> On 01/09/2023 13:08, Richard Harnden wrote:
>>>> On 01/09/2023 12:01, Bart wrote:
>>
>>>>> We are talking about compilers like gcc where you make up your own rules
>>>>> as to show strictly you want your program treated:
>>>>>
>>>>>   gcc prog.c              zero warnings, writes .exe
>>>>>   gcc @options prog.c     10000 warnings, but it still writes .exe
>>>>>   gcc @options prog.c     10000 warning and 1 error, no .exe
>>
>> Which would you choose as the one and only behaviour?

No answer? I'll look at the rest of your post, if you decide to address
this point...

--
Ben.

[Bart]

The first two examples above are for the exact same program.

For example, @options is '-Wall -Wextra -Wpedantic'; it is not defining
a new dialect.

While for errors, add -Werror, then you'll get a lot more than one!

Is my program correct? Apparently gcc can't tell me; *I* have to tell
*it*. You pretty much say that above.

OK, *I* say then that if 'gcc prog.c' works with no notes, warnings or
messages, then my program is fine.

[Kaz Kylheku]

On 2023-09-01, Bart <b...@freeuk.com> wrote:

> On 01/09/2023 13:08, Richard Harnden wrote:
>> On 01/09/2023 12:01, Bart wrote:
>>> On 01/09/2023 10:10, David Brown wrote:
>>>> On 01/09/2023 00:18, Bart wrote:
>>>
>>>
>>>>> And when there is a lot going on with gcc, you can get loads of
>>>>> warnings and other crap scrolling up the screen. So, was there an
>>>>> "error:" in there or not? I've no idea if it worked!
>>>>
>>>> Fix the problems in your source code (or choice of flags to the
>>>> compiler) - if you are getting screenfuls of errors or warnings, it
>>>> is irrelevant whether an output file was generated or not.
>>>
>>> We are talking about compilers like gcc where you make up your own
>>> rules as to show strictly you want your program treated:
>>>
>>>   gcc prog.c              zero warnings, writes .exe
>>>   gcc @options prog.c     10000 warnings, but it still writes .exe
>>>   gcc @options prog.c     10000 warning and 1 error, no .exe
>>
>> Don't worry about 10,000 warnings/errors; Fix the first one, and
>> recompile.  Rinse/Repeat.
>
> You're joking, right? Maybe some of them I need to do something about,
> but most of them are irrelevant:
>
> cc.c:5363:5: warning: ISO C forbids initialization between function
> pointer and 'void *' [-Wpedantic]
> 5363 | &cc_genasm$stropndx,
> | ^

The word "pedantic" is a slightly pejorative term. Someone in GCC,
perhaps Richard Stallman himself, introduced this diagnostic category in
order to capture certain overly nitpicky diagnostics required by ISO C.

Mainly these are in areas in which GNU C differs, providing a
nonconforming extension, like allowing a certain conversion. The
extension is only noncoforming because the required diagnostic is not
emitted; -Wpedantic makes it conforming.

-Wpedantic is used by those who are looking to write maximally portable
code that doesn't violate any ISO C constraint rule. Under -Wpedantic,
you will not accidentally use a GNU C extension.

If the code is relying on extensions like function pointer and
object conversions, it makes sense not to use -Wpedantic.

> You can't turn a 64-bit void* pointer on x64 into a 64-bit function
> pointer? **** off!

You obviously can, but ISO C requires a diagnostic. This is an extension
that makes sense on systems in which code and data are in the same
memory space, and the void * pointer is large enough to hold the
function pointer.

ISO C (a document you will likely only know about by word of mouth but
not actually read) lists this in its Annex as a common extension.

> Or unused labels. Or unused parameters (in a suite of functions that
> must share the same set).
>
> How do I discover the important ones?

By reading the GCC documentation, mainly.

One approach would be to use -Wall and perhaps -Wextra.

Then if you run into some bugs you can reactively check the compiler
documentation to answeer the question "could the compiler have
caught this issue?"

Or you can proactively do this: go "shopping" through the documentation
to get an idea of what kinds of diagnostics are available that look like
they might be useful for your project.

You can experiment with them to see whether they find something,
and what the false positive ratio is like.

> This is for generated code. The fact is, WHATEVER I do, somebody can
> just ramp up the options further to make it show a diagnostic.

If you trust your generated code, then disable warnings. Your
compiler front end should have done all the diagnosis, and the
C that is output is just being used as a "high level assembly language".

You, the compiler writer, should have done the groundwork to validate
that the way you're using the C language, with that specific compiler it
is intended for, yields the correct behavior which implements the intent
of your language.

You should dictate all code generation and diagnosis options.

Or else, you could write your compiler such that it outputs
strictly conforming ISO C, intended to be compiled by any compiler
with its highest or close-to-highest diagnostic levels.

Identify a target set of compilers and test with all of them,
working toward tweaking your generator to eliminate all warnings
(without generating code variants specific to any of the compilers).

That would mean that you don't get to convert function pointers
and void *.

Or you could target "almost strict ISO C, except that function pointers
are converted to and from void *".

> The simple solution is for me to stipulate the compile options, or for
> me to control the process (by my backend invoking the compiler directly).

That is wise.

>
> Apparently, you can do that with gcc: it's one positive, if bizarre,
> aspect of it.

What's bizarre about a tool having documented configuraton options which
it obeys?

> It's bizarre because *I*, as user, have to tell an actual C compiler how
> to compile my code, what to treat seriously, and what to disregard.

In the area of warnings, most warnings should be taken seriously.

But warnings are a an area of active development.

When GCC gets a new warning option, and people enable it, some
people find that it is triggered hundreds of times in their
code base.

So, they want that warning, but at the same time are inundated with
violations.

The configurability lets people choose.

E.g. a developer can be assigned to work (on a branch of the code)
to fix the hundreds of instances of the new warning. So GCC is
helpful to that workflow. The developer turns it on locally, gets
the diagnostics and goes about fixing them, making one or more
commits to the branch.

Then when his branch is merged to the product trunk, the warning
option can be turned on on the trunk.

Make sense?

Some projects turn all warnings into fatal errors. On such projects, the
shiny new diagnostic option cannot be turned on. It won't simply cause a
ream of nuisance messages in the build log, but fail the build.

> In other words, I have to do half its job for it. Including finding out
> whether it's has succeeded!

I don't think GCC ever terminates normally, with a failed termination
status, without emitting a diagnostic. (Maybe there is a special mode
for that?)

You must be running into a case where GCC is crashing (without having
emitted any diagnostic), and you're running it from a command
interpreter or other program which neglects to report that the child
program has abended.

Here is a dime, get a better command interpreter?

[Scott Lurndal]

As a note, early C compilers did not support mixing -o and -c. That
capability came later.